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PREFACE 


This  manual  describes  the  riser  Requirements  Languaqe  (ORL)  to  be 
used  with  Version  R.2  of  the  User  Requirements  Analyzer  (URA) . 

The  manual  consists  of  two  parts.  Part  I gives  a detailed 
description  of  the  language  statements  available  and  their  use. 
Part  IT  is  a reference  manual  which  gives  the  proper  syntax  for 
each  statement. 


FOREWORD 


'Isfir  Requiremonts  Language  (DPI.)  is  a language  for  describing  an 
Infcrmation  Processing  System  (IPS).  A Problem  Statement  (PS) 
in  npL  can  be  used  to  describe  the  "present"  system  or  to  state 
reouirements  that  a "proposed"  target  system  is  to  fulfill, 
"(escribing  the  "present"  system  is  helpful  in  finding  where 
redundant  information  exists,  standardizing  procedures,  etc., 
and  also  forms  the  basis  for  designing  "proposed"  systems.  In 
describing  a "proposed"  system,  the  Problem  Statement  can  be 
considered  as  the  specifications  for  the  succeeding  stages  in 
the  system  life  cycle,  i.p.,  in  the  physical  design  and 
construction  ohases. 

Requirements  for  proposed  information  processing  systems  are 
usually  described  in  the  Logical  System  Design  phase  sometimes 
called  the  "feasibility  study."  The  end  result  of  the  logical 
system  design  process  is  a description  of  a proposed  system  and 
a benefit/cost  analysis  of  the  value  of  building  it.  The 
process  itself  may  be  accomplished  in  many  different  ways  but 
the  particular  method  chosen  does  not  affect  the  form  of  the 
final  result,  what  constitutes  a satisfactory  description  of 
the  proposed  svstem  is  not  affected  by  whether  the  process  is 
carried  out  manually  or  with  computer  aids  (except  for  the  fact 
that  the  comouter-aided  method  can  result  in  the  descriotion 
itself  being  storel  in  a computer-aided  processable  form)  . 

■"he  purpose  of  the  manual  is  to  describe  how  URL  may  be  used  to 
describe  systems.  Tt  may  be  used  as  an  introduction  to  the  usa 
of  nPL  and  is  also  used  as  a text  in  ORL  courses.  It  contains 
the  complete  syntax  and  semantics  of  URL  as  well  as  providing 
guidelines  on  how  these  are  intended  to  be  used.  A more  precise 
statement  of  URL  is  given  in  the  User  Requirements  Language, 
Language  Reference  f'anual.  Part  II.  Additional  information  in 
the  use  of  URA  givsr  in  the  User  Requirements  Analyzer  User’s 
Manual. 
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1.  INPOFMATIDN  PROCESSING  SYSTEM  DESCRIPTION 

Infcrniation  Processinq  Systens  of  all  types  exist  in 
ocq anira tions  today.  They  serve  to  store,  retrieve,  manipulate 
or  orqanire  information  in  some  manner  to  meet  a particular 
organisation's  needs.  For  this  reason,  the  design  and  operation 
of  one  of  these  systems  are  oarticular  to  a given  organization. 
To  conform  with  the  changing  environment,  an  organization  must 
develop  new  systems,  modify  exist ing  systems  and  terminate 
obsolete  ones.  '"his  can  require  a major  effort  of  the 
organization  to  design  systems  and  maintain  documentation  of  a 
system  once  it  is  operational. 


Introduction 


1.1.1  S vstem  Life  I ycle 

An  information  processing  system  has  a life  cycle  which  begins 
with  the  initial  conception  of  need  of  the  system,  proceeds 
through  determination  of  requirements  for  the  system,  (logical 
system  design),  physical  system  design,  detailed  design  and 
construction,  operation,  modification  and  maintenance  and 
finally,  termination  of  system  operation. 


1.1.2  Documenta  tion 

At  each  step  of  the  life  cycle,  some  form  of  documentation  is 
needed  by  the  organization.  The  documentation  consists  of  a 
complete  and  comprehensive  description  of  the  proposeel  (or 
target)  system.  In  addition,  the  organization  of  which  the 
system  is  part  must  be  at  least  partially  described;  and  the 
oroject  defining  and  designing  the  system  must  also  be 
described. 


1. 1.2.1  What  has  to  be  Documented 

No  matter  what  type  of  system  is  to  be  designed  or  who  is 
designing  it,  there  exist  some  features  or  components  which  are 
common  to  all  systems  and  that  must,  therefore,  be  included  in 
its  documentation.  Together,  these  common  characteristics  can 
be  regarded  as  constituting  a model  of  the  system.  This  model 
is  shown  in  Figure  1. 

The  basic  purpose  for  constructing  a system  is  to  serve  some 
organization.  usually,  a new  system  is  required  to  solve  some 
"problem"  within  the  existing  system. 


PAR""  T 


USER  REQUIREMENTS  LANGUAGE  MANUAL 


rBM360/370/VS/TSO  DEL  USER'S  MANUAL 


2 


♦ -- 

I 

I 

I 

4.  ---4' 

T I 

T T 

I ENVIRONMENT  I 
I I 

4. — 4. 

I 

I 

I 

4. 


4._-..--_— . — -4. 

T I 

I I 

I SYSTEM  I 

I I 

4.... -..4 


problem  boundary 


- 4 

I 

I 

I 

4-—.-.-.--.—  -4 

I I 

I I 

I ENVIRONMENT  I 
I I 

4 — 

I 

I 

! 


’'igure  1;  The  Problem 


The  tasV  of  the  system  builders  is  to  accurately  define  the 
problem  so  that  a solution  may  be  implemented.  The  problem, 
therefore,  has  three  basic  components  or  elements: 

- An  environment  in  which  the  problem  occurs.  Those  parts  of 
^he  organiration  which  directly  interface  with  the  problem  must 
be  included  in  the  description. 

- The  target  system  which  is  being  described  to  resolve  the 
problem.  The  word  "target"  connotes  a "proposed"  rather  than  an 
existing  system.  The  relation  between  the  environment  and  the 
target  system  is  shown  in  Figure  1. 

- The  Progect  assigned  the  task  of  defining  the  problem, 
adeguately  documenting  the  requirements,  designing,  constructing 
and  installing  the  system. 

All  of  tho  elements  must  be  documented  in  sufficient  detail  to 
meet  the  needs  of  the  organization.  To  accomplish  this,  the 
elements  must  be  broken  down  to  smaller  components.  These  in 
turn  must  be  broken  down  or  subdivided  into  smaller  elements. 

The  elements  at  all  levels  are  called  the  "system  description 
elements. " 


1. 1.2.2  Pur  pose  s of  Documen  tation 

The  description  of  the  problem  throughout  the  life  cycle  is 
usuallv  referred  to  as  "documentation."  Such  documentation  must 
sorve  a number  of  different  purposes: 

- The  system  builders  must  have  a record  of  what  they  have  dons. 

- The  organizations  within  the  environment  of  which  the  system 
is  To  serve  must  have  a description  to  assure  themselves  that 
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'■he  prepared  system  will  satisfy  their  needs. 

- The  Management  of  the  organization  that  is  providing  the 
resources  must  know  what  they  are  approving. 

- The  system  builders  who  will  continue  the  development, 
construction,  operation  and  maintenance  of  the  system  must  all 
have  documentation  from  which  to  carry  out  their  tasks. 

1 . 1 . 2 . 3 Fo r m s of  Documentat ion 

To  serve  their  needs,  most  organizations  have  developed  standard 
documentation  procedures  consisting  of  very  general  to  very 
specific  guidelines  in  producing  documentation.  Some 
organizations  use  commercial  documentation  packages  or 
documentation  techniques  in  hopes  of  producing  more  complete, 
correct  and  consistent  documentation. 

Tt  is  standard  practice  to  record  the  description  of  the  system 
in  formal  documents  corresponding  to  various  stages  of  the  life 
cycle  known  by  such  names  as  the  system  definition  report, 
system  requirements  report,  system  design  report,  programming 
documentation,  user's  manual,  etc. 

These  documents  are  normally  in  narrative  form,  supplemented  by 
diagrams,  flow  charts,  lists,  glossaries,  cross  references,  etc. 

1 . 1 . 2 . h Cha ract erist ics  of  System  Documentation 

Information  Processing  Systems  are  large  and  complex  and 
regardless  of  who  produces  the  documentation  or  what  graphical 
aids,  such  as  flow  charts  are  used,  it  will  have  several 
features  that  make  the  process  of  documentation  different. 

- Size.  Complete  documentation  of  a system  may  consist  of  many 
thousand  of  pages  of  charts,  tables,  code  listings,  user  guides, 
pro-ject  plans,  etc. 

- Complexity.  Any  piece  of  information  about  some  aspect  of  the 
system  or  the  project  may  be  related  to  many  other  pieces, 

- Multiple  users  with  different  needs.  Each  of  the  users  of  the 
documentation,  as  noted  above,  need  the  documentation  of  some 
aspects  of  the  system  at  different  levels  of  detail. 

- Changeability.  The  documentation  must  be  constantly  updated 
as  changes  occur  in  the  organization  or  in  the  system.  Any 
change,  because  of  the  complexity,  can  affect  the  documentation 
in  many  places. 
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1.1.3  Process  of  Documentation 

1 . 1 . 3. 1 Han  ual 

Someone  must  he  responsible  for  this  documentation.  It  is  often 
the  task  of  the  analyst  to  do  this.  In  other  cases,  it  may  be  a 
technical  writer  who  must  obtain  the  information  from  other 
sources  (analysts,  management,  memos,  etc.)  in  order  to  produce 
the  documentation  of  the  system.  The  technical  writer  has  the 
disadvantage  of  not  being  directly  involved  in  the  system 
development  effort.  The  analyst  has  the  advantage  of  being 
directly  involved  with  the  system  yet  is  sometimes  too  close  to 
it  to  present  a complete  description.  The  documentation  is 
usually  produced  manually  regardless  of  who  is  doing  it. 

1 . 1 . 3.  2 Compute r-Aided  Documentation  ~ PHL/URA 

A computer-aided  approach  to  system  documentation  can  be  an 
improvement  over  the  manual  methods  by  using  the  power  of  the 
computer  to  store  large  quantities  of  data  and  to  manipulate 
complex  relationships. 

To  take  advantage  of  the  potential  benefits,  a computer-aided 
documentation  system  should  have  the  following  characteristics: 

a)  A formal  language  flexible  enough  to  describe  any  type  of 
information  processing  system, 

b)  A translator  which  takes  the  formal  language  statements  as 
input  and  stores  it  in  some  processable  form  in  the  computer 
(i.e.,  on  disk  or  tape). 

c)  A data-base  in  which  the  information  interpreted  from  the 
language  statements  is  stored. 

d)  A report  generator  which  allows  information  in  the  data-base 
to  he  retrieved,  analyzed  and  formatted  as  reports. 

e)  An  update  facility  which  allows  information  in  the  data-base 
to  he  added  to,  modified,  or  deleted.  Before  any  information  in 
the  data-base  is  updated,  checks  must  be  made  for  consistency 
and  correctness  so  that  accuracy  of  the  information  in  the 
data-base  is  maintained. 

■"he  advantages  of  using  such  a computer-aided  technique  versus  a 
manual  method  are: 

a)  Though  information  is  interrelated  with  other  information, 
there  is  only  one  occurrence  of  each  piece  of  information  in  the 
data-base.  If  this  piece  of  information  is  modified,  the 
contents  of  the  data-base  are  modified  to  reflect  the  change. 
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b)  The  Lanq'iage  has  a finita  number  of  statements  which  may  be 
soecified  an-l  syntax  and  semantic  rules  for  each  of  these 
statements,  "’his  allows  persons  documenting  systems  to  give 
precise  descriptions  which  are  much  less  subiec’'  to 
misinterpret  at ion. 

c)  Once  the  data-base  has  been  modified,  all  reports  generated 
using  it  are  up-to-date. 

d)  The  reports  generated  are  designed  to  view  the  system  (as 
described  in  the  data-base)  at  various  angles.  One  particular 
report  mav  present  h icrh  level  structural  information,  another 
may  present  the  manner  in  which  low  level  data  is  manipulate!  in 
the  system,  and  still  others  may  present  lists  of  names, 
dictionaries,  etc. 

e)  3oine  reports  may  present  results  of  complex  analysis  based 
on  the  contents  of  the  data-base.  Analysis  may  consist  of 
checks  for  completeness  or  consistency  in  the  system  description 
at  any  point  in  time. 


‘'.1.3.3  URL/UPA 

URL  is  a computer-processable  language  designed  primarily  o 
describe  a target  system  during  its  formativ®  stage  (i.e., 
during  the  determination  of  requirements  phase  in  the  system 
life  cycle)  . It  also  contains  facilities  for  describing  those 
parts  of  the  organization  interfacing  with  the  system  and  those 
parts  of  the  progect  which  are  relevant  to  the  description  of 
the  target  system.  The  URL  description  of  a system  consists  of 
a combination  of  formal  statements  (allowed  by  the  language) 
supplemented  by  narrative  descriptions. 

The  User  Requirements  Analyzer  (DRA)  is  a software  package  which 
processes  the  URL  statements  and  acts  as  an  interface  between 
the  problem  definers  and  the  information  stored  as  the  URL 
description . 

Organizations  usually  require  that  the  documentation  of  a 
proposed  system  include  a "system  requirement  report."  This 
document  contains  a detailed  description  of  the  target  system, 
information  about  the  manner  in  which  the  system  interfaces  with 
the  organization,  and  some  description  of  the  project  designing 
the  system  including  estimates  of  costs,  resources  required  and 
completion  time,  etc.  URL  is  designed  to  state  the  type  of 
information  which  appears  in  the  system  requirement  report  and 
when  a problem  is  completely  described,  essentially  all  the 
information  for  the  system  requirement  report  is  contained  in 
the  URA  data-base. 


1 . 1 . 14  Introduction  to  URL  - A Formal  System  Descript  ion  Language 
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The  description  of  a system  involves  describing  "objects,"  the 
"properties"  of  these  objects,  and  the  "relationships"  among  the 
objects . 

In  Section  1.1.2  these  "objects"  were  referred  to  as  "system 
description  elements"  representing  some  physical  or  conceptual 
thing  in  the  target  system.  Examples  of  "objects"  are  "logical 
collections"  of  data,  the  "processes"  which  define  how  the  data 
is  derived,  eto  . Each  "object"  defined  in  the  target  system 
must  be  assigned  a unique  name  and  classified  by  the  "type"  of 
object  which  it  is.  URL,  for  example,  allows  approximately  30 
different  types  of  "objects." 

"Properties"  of  an  "object"  consist  of  statements  describing 
that  "object." 

"Re lationsh ins, " on  the  other  hand,  describe  connections  among 
"objects."  To  say  that  object  A uses  objects  B and  C specifies 
"relationships"  among  these  objects.  There  are  approximately  75 
different  "relationships"  that  may  be  used  in  URL. 

An  example  of  a description  of  a (very  simple)  system  is  given 
in  Section  1.2.  A full  description  of  the  types  of  "objects" 
that  may  be  defined  in  URL,  their  purposes  and  usages,  is  given 
in  Section  1.3.  The  "relationships"  allowed  in  URL  are  given  in 
Section  1.4  along  with  information  on  how  these  relationships 
relate  to  the  overall  system  description  and  special 
considerations  involved  whan  using  them. 


1 . 2 Fxa  mple 

""his  section  illustrates  the  fundamental  concepts  of  objects, 
names  of  objects,  types  of  objects  and  relationships  among 
objects  through  the  use  of  a simple  example.  The  process  of 
computer-aided  documentation  is  also  shown.  (Properties  of 
objects  are  not  illustrate!  in  this  example.) 


1.2.1  Narra t ive  Descri ption 

The  following  is  a typical  narrative  description  of  a particular 
system ; 

"A  system  called  payroll  processing  takes  employee 
information  which  comes  from  departments  and  employees  and 
produces  outputs  which  go  to  the  departments  and  employees. 
The  system  also  maintains  payroll  master  information." 

"^he  information  in  such  a narrative  description  is  usually  shown 
graphically  as  in  Figure  1.2.1  or  in  Figure  1.2.2. 
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Figure  1.2.2 


System  Flowchart  for  PAYSYSTEM 
Using  Standard  Flowchart  Symbols 


1.2.2  Identification  of  Objects 

The  first  step  in  using  URL  is  to  identify  the  objects  in  the 
svstem  being  described.  This  can  be  done  for  the  above  example 
bv  underlining  them  in  the  narrative  description; 

"A  system  called  payroll  processing  takes  gmployee 
in  forma  tion  which  comes  from  departments  and  employees  and 
produces  outputs  which  go  to  the  departments  and  employees 
. The  system  also  maintains  payroll  master  information  ." 

1.2.3  Object  Names  and  Types 

Each  of  the  defined  objects  has  a unique  name  and  each  of  these 
objects  is  described  in  a different  context;  "employee 
information"  represents  information  passing  from  "departments 
and  employees"  to  "payroll  processing,"  "payroll  master 
information"  represents  information  manipulated  by  "payroll 
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processing,"  etc.  In  effect,  each  of  these  objects  represent 
(lifferent  types  or  classes  of  objects.  For  example,  in  URL,  '■he 
type  of  object  corr espondina  to  that  suggested  by  "employee 
information"  is  an  INPUT,  "payroll  master  information"  is  a SFT, 
etc.  The  following  table  relates  each  of  the  objects  defined  in 
the  narrative  description  with  a corresponding  URL  name  and 
object  type: 


URL 

Object 


Narrative 

URL  Name 

liEe 

payroll  process 

inq 

pay roll- processing 

PROCESS 

employee  inform 

atio  n 

employee-i nfor mation 

INPUT 

departments  and 

empl cyee  s 

depa  r traent  s-and-eaployees 

INTER- 

FACE 

outputs 

p ays ys tern- out  pu  ts 

OUTPU'" 

pavrcll  master 

inf  o r ma  ti  on 

pay roll-mas ter- inf or mat ion 

SET 

URL  does  not  allow  blanks  in  the  names  of  objects;  dashes  are 
normally  used  to  connect  names  consisting  of  more  than  one  word. 
In  an  effort  to  keep  the  names  used  as  meaningful  as  possible, 
"qualified"  names  such  as  " paysystem-outputs"  (instead  of 
"outputs")  are  encouraged. 

1.2.h  I dent i f Ic  at ion  of  Relationships 

The  next  step  in  using  URL  is  to  identify  the  relationships 
among  the  objects  which  have  been  identified.  The  relationships 
implied  in  '•he  example  narrative  description  are  underlined: 

"A  system  called  payroll  processing  takes  employee 
information  which  comes  from  departments  and  employees  and 
produces  outputs  which  <jo  to  the  departments  and  employees. 
The  system  also  maintains  payroll  master  information." 


The  followinq 

relationships  have  been 

identified: 

Relationshi  d 

Between 

and 

takes 

oayroll  orocessino 

employee  information 

comes 

employee  information 

d epartments 

and  employees 

pro  d uces 

payroll  processing 

o utputs 

go 

outpu  t s 

departmen  ts 

and  employees 

maintains 

oayroll  processinn 

payroll  master  informatio 

There  are  a finite  number  of  relationships  that  may  be  described 
by  OFL.  3y  taking  into  account  the  types  of  objects  defined  in 
the  above  example  and  the  relationships  that  URL  allows  among 
those  objects,  the  following  correspondence  between  the 
narrative  description  relationships  and  the  URL  relationships 
can  he  made: 


PART 
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Nai  rat  i VR  £fl3!ii2D5lji£ 


URL  relationship 


ta  kes 
CO  mes 
produces 
qo 

tnainta  ins 


RECEIVES 
GENERATED  BY 
GENERATES 
RECEIVED  BY 
UPDATES 


The  description  of  the  system  using  URL  terninology  is; 


Obi  ect 


Relationship  0 bject 


n^v  tcl 1-process inq 
empl ovee- in  forma tion 
pay rol 1- process inq 
pay  syst  em-o  utpu  ts 
payroll -pro cess inq 


RECEIVES 
GENERATED  BY 
GENERATES 
RECEIVED  BY 
UPDATES 


employee- i nforaat ion 
departments-and-employees 
paysystem- out  puts 
depart men  ts-and-eaployees 
payroll- master- in  formation 


1.2.5  URL  Format 

The  obqect  type  of  a particular  named  object  can  be  explicitly 
defined  by  a UPL  statement.  For  the  above  example,  the 
following  Upl  statements  may  be  used  to  define  the  object  type 
of  "payroll  processing,"  "employee  information"  and  "departments 
and  employees." 

PROCESS  payroll-processing; 

INPUT  employee-information; 

T N" ERE ACE  department  s- and- employees; 


Since  a particular  object  may  be  involved  in  several 
relationships  the  format  for  specifying  relationships  is  made  as 
simple  as  possible.  For  any  object  defined  via  a statement 
declarinq  its  object  type  (as  above)  those  relationships  the 
object  is  involved  in  may  be  listed  after  this  statement  along 
with  the  corresponding  objects  in  the  relationship.  The  URL 
format  to  specify  the  relationships  "payroll  processing"  is 
involved  in  is; 


PROCESS 
RECEIVES 
GENEP ATES 
UPDATES 


pa  y roll- processing ; 

em  ployee-inf ormaticn; 

pa  y system- outputs; 

pay rol 1-master- informa  tion; 


1 . 2 . f UPA  0 utpu  ts 

One  complete  URL  problem  statement  for  the  example  is  shown 
below.  (There  are  many  ways  in  which  all  of  the  information 
could  be  stated.  They  are  all  equivalent  as  far  as  USA  is 
concern  ed. ) 
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T N F 

ODTPHT 

SET 

r NTEF  FACE 
GENEPA'^  E.F 
PEC2IVES 
PPCCFSF 
UPDATES 
PECEIVES 
GEKEFATES 


em  ploy f"- information; 
pa  V sy s t t^n  - ou  t puts  ; 
pa  y rol l-ma  ster- j nf orma  tion ; 
depart  mf'nts-and-employees; 
employee- informa tion; 
paysvKt3ra-ou*’puts; 
payroll- processinq; 

pay roll-master- information; 
eraplovee-information ; 
pay system-outputs; 


Onoe  these  statements  have  b^^en  entered  into  the  UP  A data-base, 
UPA  can  be  used  to  aenerate  a number  of  "standard”  outputs. 
Fiqure  1.2.  3 shows  one  of  these  outputs  called  the  P0E!1A"'TED 
PBOPLEF  STATEMEM'^.  This  report  contains  all  information  stored 
about  selected  objects  in  the  data-base.  In  this  instance,  the 
report  has  been  qenerated  for  all  the  objects  defined  in  the 
data-base. 


The  format  of  the  information  in  the  FORMATTED  PROBLEM  STATEMENT 
is  the  same  as  that  specified  when  describing  the  example  in 
URL.  The  report  also  presents  all  implied  relationships  as  well 
as  the  explicitly  defined  ones.  This  is  the  reason  that,  thouqn 
only  five  r ela*"  ion  sh  ips  were  given  in  the  example,  ten  are 
presented  in  the  F0PMA"'TED  PROBLEM  STATEMENT.  ' To  say  that 
'payroll-processing'  RECEIVES  'employee-information'  implies 
that  'employee- information ' is  RECEIVED  BY  ' pay  roll- processing,  ' 
etc.  These  are  called  complementary  statements  and  when 
describing  a system  in  URL,  the  choice  of  which  of  the  two 
complementary  relationships  to  be  used  is  arbitrary.  (The 
information  stored  in  the  data-base  is  exactly  the  same.)  The 
following  are  the  c o nplemen ta r y relationships  used  in  the 
example  ; 

Relationship  Complementary  Relationship 


RECEIVES 

GENERATES 

UPDATES 


RECEIVED  BY 
GENERATED  BY 
UPDATED  BY 


Figure  1.2. h presents  an  example  of  a graphical  output  that  may 
be  obtained  from  URA.  This  particular  example  shows  the 
relationships  ' pavroll-processino’  is  involved  in.  All  objects 
are  represented  by  rectangles  with  the  name  of  the  object  within 
the  rectangle  and  ’■he  type  of  the  object  is  given  on  the  top 
line  of  the  rectangle. 


The  rectanole  for  the  name  for  which  the  output  is  being 
generated  is  placed  at  the  center  of  the  diagram.  All  other 
objects  are  placed  along  the  left  and  right  margins  if  involved 
in  "flow"  relationships,  and  along  the  top  or  bottom  margins  if 
involved  in  "structure"  or  "updating"  relationships.  The  type 
of  relationship  the  center  object  has  with  bordering  objects  is 
given  on  the  bottom  line  of  the  rectangle  for  each  of  the  border 
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obifcts.  In  the  diaqran,  ' pi yrol 1- processing ' RECEIVES 
' eiB  ployee- i n f or  mat  i on,  • etc. 

In  ♦•his  eximnle,  naines  of  objects  have  been  shown  in  lower  case 
letters  and  Types  of  Objects  and  Relationship  in  upper  case 
letters.  It  is,  therefore,  easy  to  distinguish  user  assigned 
names  for  objects  from  words  which  are  part  of  URL.  The  ability 
•■o  distinguish  lower  and  upper  case  letters  depends  on  the 
facilities  available  in  the  installation  in  which  URA  is  being 
used.  If  the  installation  does  not  support  lower  case  letters, 
all  words  and  names  will  appear  in  upper  case. 


1 . 3 URL  Objects 

<V  URI  object  is  anything  given  a URL  na»e  by  the  user  of 
TIPL/UPA  . Each  object  is  given  a unique  name  so  it  can  Pe 
identified  each  time  it  occurs  in  the  system  description. 
Consequently,  all  occurrences  can  be  collected  and  analyzed.  A 
URL  name  is  one  that  conforms  to  the  rules  of  name  formation  in 
the  UFL/UPA  system  (Section  1.6).  Once  any  particular  object 
has  been  given  a name  it  can  be  included  in  relationships  only 
by  specifying  its  name. 

Each  object  must  be  a certain  object  type.  The  complete  list  of 
oermissible  types  in  alphabetical  order  is  given  in  Figure  1.3.1 
together  with  the  allowable  abbreviations  for  each  object  type. 
Of  ♦■hese,  two  are  "SDecial"  types;  SYNONYM  and  UNDEFINED.  If 
the  object  type  of  an  object  is  not  declared  explicitly,  ORA  may 
be  able  to  deduce  the  object  type  from  the  manner  in  which  the 
object  is  used,  otherwise,  the  object  type  for  the  name  will  be 
"UN CEFI NED. " A Problem  Statement  is  not  complete  if  it  contains 
any  UNDEFINED  names.  A SYNONYM  is  a special  type  of  object  that 
can  be  used  only  as  an  alias  or  pointer  to  one  other  name,  e.g., 
an  object  that  has  been  assigned  the  name  'validation- 
processing' nigh'-  be  given  synonym  'valpr.' 
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0 h ject  2X22 

Ahbrevi at  ion 

A TTPI 

ATTR 

ATTRIBUTE- VALUE 

ATT  V 

CLASSIFICA'''^ON 

CLS 

CONDITION 

CCND 

ELEMENT 

FLE 

ENTI"'Y 

FNT 

EVE  NT 

FVT 

GROUP 

GR 

INPUT 

INP 

INTEPPACS 

INTF 

TNTEPVAL 

INT 

KEYWORD 

KEY 

M AILBOX 

POX 

m EMO 

— 

OUTPUT 

OUT 

PRCBLEM-DEETNFR 

PD 

PRCC’^SS 

PRC 

P RCCESSOP 

PPCR 

R El  A” TON 

PLN 

E E SOU  PC’' 

PSC 

PPSOUECS-UTAG E-UA PAKETEE  PUP 

3ECUFITY 

SEC 

S (^CE 

SRC 

p »r 

w M 

SnpSETTTNG-CFTT'‘RTON 

SSCN 

SYNONYM 

SYN 

SYSTEM-UA 

SYSP 

TR  ACE-KEY 

TKEY 

UNDEFINED 

— 

UNIT 

— 

FiTire  1.3.1  Ob-jcct  Types  and  Abbreviations 


1.3.1  Classification  of  Objecjt  Types 

For  ease  of  describing  the  purpose  and  characteristics  of  each 
♦■ype  of  obieC-  with  respect  to  the  system  documentation,  it  is 
convenient  to  group  the  types  into  classes.  The  list  of  classes 
and  object  types  within  each  class  if  shown  in  Figure  1.3.2.  It 
must  be  emphasized  that  classification  is  for  exposition  only 
and  plays  no  role  in  '•he  formal  syntax  or  semantics  of  UFL.  The 
major  categories  of  classification  are  the  following: 

Oroanization  for  objects  used  to  describe  the 

organization  or  environment  in  which  the 
target  system  is  to  operate. 

■"aroet  System  for  objects  used  to  describe  the  target 

system . 
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Proiect  M=\nafie™p‘nt  for  ob-jects  use3  to  describe  the  project 

developing  the  target  systen. 

Properties  for  objects  used  to  describe  the  objects 

in  the  above  three  categories. 

■"he  purpose  and  characteristics  of  each  object  type  is  described 
belov  in  the  order  in  vhich  listed  in  Figure  1.3.2.  The 
relationships  in  which  an  object  of  a given  type  can  be  included 
is  outlined  in  Section  1.4,  and  given  in  more  detail  in  Sections 
2 and  3.  (The  precise  syntax  is  given  in  the  "User  Requirements 
Language,  Language  Reference  Manual."*)  A discussion  of  the  role 
of  each  object  type  and  situations  in  the  system  description 
orocfss  whether  it  should  or  should  not  be  used  is  given  in 
Section  4, 


1.3.2  0 rgan izat ion  Objec  ts 

■"he  URL  object  used  to  describe  seme  part  of  the  organization  or 
environment  with  which  the  target  system  interacts  is  called  an 
INTEP'^ACE  (or  R EAL- WCRLD-ENTITY)  . INTERFACES  are  often  used  to 
■'escribe  departments  in  an  organization  or  other  information 
processing  svstenis  which  interface  with  the  target  system. 
Interfaces  are  sometimes  called  by  such  names  as  "stations," 
"organi7a»-ional  units,"  etc.,  in  other  documentation  systems. 

Interfaces  are  objects  which,  as  far  as  the  target  system  being 
developed,  may  receive  data  from  it  or  transmit  data  to  it.  For 
example,  if  a warehouse  stock  control  system  were  being 
designed,  interfaces  might  be  suppliers,  customers,  the 
accounting  department,  etc.  They  are  not  part  of  the  target 
svstem,  but  have  important  relationships  with  it.  Though  the 
functions  of  an  interface  may  be  complex,  only  the  description 
nertaining  to  its  relationships  with  the  target  system  are  of 
importance.  Interfaces  should  be  described  if  they  generate 
information  to  the  target  system,  receive  information  from  the 
•■arget  system,  or  are  responsible  for  information  within  the 
target  sys'-em. 

* Part  II  of  this  document 
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CL^S  03  OBJECT  TYPES 

OBJECT  TYPES 

INTERFACES  OR  ORGANIZATIONAL  UNITS 

INTERFACE  ( REAL- 
WORLD- E NTI  TY ) 

[ '^ARGET  SYSTEM 

1 

t CCILECTIONS  OF  INFORMATION 

(EXTERNAL) 

(INTER  NAL) 

INPUT 

OUT  PUT 

ENTITY 

CCLIFCTIONS  OF  INFORMATION  INSTANCES 

SET 

‘ REIATIONSHIPS  AMONG  COLLECTION  OF 

1 INFORMATION 

RELATION 

DATA  DF’^INTTION 

GROUP 

ELEMENT 

i DATA  DERIVATION 

PROCESS 

> SIZE  AND  VOLUME 

SYSTEM- PARA  ME  TER 
INTERVAL 

1 DYNAMIC  BEHAVIOR 

EVENT 

CONDITION 

SYSTEM  ARCHITECTURE 

PROCESSOR 

RESOURCE 

RESOURCE- 

nSAGE-PARAMETEH 


UNI  ? 


PROJECT  MANAGED 


PROBLEr.-DEFINSR 

MAILBOX 


PROPERTIES  SYNONYM 

K’^’YWOPO 

ATTRIBUTE 

ATTFIPUTE-V  ALUE 

CLASSIFICAI ION 

MEMO 

SOURCE 

SEC URITY 

TRACE-KEY 


O'^HE?  UNDEFINED 


Fiqure  1.3.2  Classification  of  Obioc*  fyp-as 
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1.3.3  Targe t System  Objects 

Target  system  objects  are  used  to  describe  the  target  system 
with  respect  to  forms  of  information,  processing  of  the 
information,  behavior  of  the  system  over  time,  etc. 


1.3. 3.1  Col lect ions  of  I nf orma tion 

Information  related  to,  or  pertaining  to,  one  particular  type  of 
thing  or  concept  is  thought  of  as  a collection  of  information, 
’'or  example,  '’employee  information"  may  be  a collection  of  all 
information  pertaining  to  a particular  employee.  This 
information  would  be  derived  when  an  employee  is  hired  by  the 
company,  used  to  produce  paychecks  for  the  employee,  updated  to 
reflect  changes  in  the  employee's  status,  address,  etc.  The 
collection  is  to  he  thought  of  as  a whole  (in  the  above  example, 
everything  that  had  to  be  known  about  an  employee)  though  in 
being  processed  by  the  target  system,  only  portions  of  the 
collection  might  be  used  at  any  one  time.  There  are  three  typas 
of  collections  of  information  that  may  be  defined  in  URL: 

INPUTS,  OUTPUTS  and  ENTITIES.  The  difference  among  these  types 
of  collections  is  related  to  their  role  in  the  target  system. 


INPUTS 

An  INPUT  is  a collection  of  information  produced  external  to  the 
target  system,  but  used  by  the  target  system.  For  example,  in 
an  inventory  svstem,  a customer  order  may  be  considered  an  INPUT 
to  the  system. 


0 U'’'PUTS 

An  OUTf'JT  is  a collection  of  information  produced  by  the  target 
system,  hut  which  is  I’sed  external  to  the  system.  For  example, 
the  oaychecks  nroiu<-.d  by  a payroll  processing  system  could  be 
thought  of  as  OUTPUTS  as  they  are  eventually  used  by  employees 
ou’- side  of  the  system.  Once  the  collection  has  left  the  system, 
no  further  reference  may  be  made  to  it. 


ENTITIES 

An  ENTITY  is  a collection  of  information  which  is  maintained 
in’-ernal  to  the  system.  ENTITIES  are  initially  "produced"  and 
then  "maintained"  using  information  from  INPUTS  and  then  OUTPUTS 
are  produced  using  information  from  ENTITIES.  The  "employee 
information"  described  above  in  the  definition  of  "Collections 
of  Information"  is  an  example  of  an  ENTITY. 

All  cf  ’■ho  above  types  of  collections  of  information  may  belong 
to  larger  collections  and  may  be  broken  down  into  smaller  units 
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of  information.  Consequently,  there  may  he  "structural" 
relationships  between  particular  obiects  of  these  types. 

i.3.J.2  Collections  of  Informa  tion  Instances 

A number  of  instances  of  one  cr  mere  collections  of  information 
is  called  a SE? . For  example,  a SET  miqht  be  defined  to 
describe  all  instances  of  "employee  information"  in  the  target 
system.  There  is  an  important  distinction  to  be  made  between  a 
collection  of  information  and  an  instance  of  this.  Information 
called  "employee  information"  is  a collection  of  information, 
but  employee  information  about  JACK  SMITH  is  an  instance  of  the 
collection  of  information.  A number  of  instances  together  may 
cons*-itute  a SFT  of  "employee  information."  Likewise,  if  two 
collections  of  employee  information  were  maintained  (one  for 
current  employees  and  one  for  retired  employees)  a SET  could  be 
defined  to  contain  instances  of  both  collections  as  well  as 
defining  a separata  SE"’  for  each  collection  of  information  about 
the  different  t vpes  of  employees. 

The  common  examole  of  a SET  is  a master  file  consisting  of 
records,  i.e.,  EV"ITIFS,  for  each  employee.  However,  SET  may 
also  consist  of  INPUTS  and  OUTPUTS.  This  permits  SETS  to 
represent  collections  of  INPUTS,  e.g.,  queues  of  messages  to  be 
processed . 


1.3. 3. 3 Eelntionshi DS  Among  Collections  of  Information 

Collections  of  information  maintained  internal  to  the  system 
(ENTITIES)  are  often  "related"  to  each  other  in  that  there  is 
information  which  is  not  inherent  to  either  yet  is  associated 
with  both.  In  the  example  of  a warehouse  stock  control  system, 
information  about  inventory  items  may  be  related  to  information 
about  ^heir  ywpnliers,  etc.  RELATIONS  are  used  to  describe 
logical  connections  among  ENTITIES. 


1 . 3 . 3 . U Da  t a De  f ini  t ion 

Collections  of  information  (INPUTS,  OUTPUTS  and  ENTITIES) 
"contain"  values  of  information  called  ELEMENTS  and  GP:iUPS. 


ELEMENTS 

ELEMENTS  are  the  basic  unit  of  information  and,  therefore, 
cannot  be  subdivided.  An  ELEMENT  is  used  to  describe  a data 
obgect  which  may  take  on  a value.  For  example,  if  "employee 
information"  was  defined  to  be  an  ENTITY  it  would  not,  in 
itself,  have  a value.  The  ELEMENTS  making  up  "employes 
information"  such  as  "age,"  "sex,"  "salary,"  etc.,  might  have 
values  for  a particular  instance  of  "employee  information." 
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nPOMPS 

r.pntips  to  describe  a collection  of  ELEMENTS  and/or 

other  GRODPS.  GPOUPS  allow  the  problem  definer  to  logically 
relate  one  or  more  ELEMENTS  and/or  GROUPS  together  and  refer  to 
them  collectively  bv  the  GROUP  name. 

GROUPS  can  be  thought  to  ba  synonymous  with  the  names  of  the 
GROUP'S  coraporents.  In  the  example  of  "employee  information," 
the  "name"  of  the  employee  may  he  defined  as  a GROUP  where  the 
con stit uten t s of  the  GROUP,  "first  name,"  "middle  initial," 
"surnam«"  may  he  defined  as  ELEMENTS.  The  use  of  GROUPS  is 
primarily  a notational  convenience. 


1.d.3.S  Data  Derivation 

An  information  processing  system  exists  to  process  data,  i.e., 
to  produce  data  values  from  other  data  values.  This 
transformation  is  known  by  different  names  such  as  process, 
procedure,  function,  operation  activity,  etc.  In  URL,  a PROCESS 
is  the  type  of  obgect  used  to  describe  this  transformation. 

^he  total  target  system  can  be  regarded  as  a PROCESS  at  the 
hiahest  level.  A PROCESS  is  defined  by  specifying  the 
information  upon  which  it  operates  and  the  information  which  it 
prod  uce  s . 


1 . .1  . 3 . f ^nd  y2liiS!£ 

■)bgec*-s  which  rela*-e  information  pertaining  to  the  amount  of 
information  maintained  by  the  system  and  volume  of  information 
to  he  processed  are  described  to  estimate  the  size  of  the  target 
system. 

Information  about  the  size  of  a proposed  target  system  is 
usually  stated  in  terms  of  numbers.  E.q.,  500  employee  changes 
occur  each  pav  period  or  production  analysis  report  consists  of 
100  pages. 

In  nPL,  the  "parameters"  affecting  the  size  of  the  system  are 
considered  obgects  and  each  given  a unique  name:  two  types  of 
ohiects  are  permitted: 

R M-PARAMETERS  and  time  INTERVALS 

■"he  basic  purpose  of  treating  these  parameters  as  objects  is 
that  eacji  occurrence  can  be  uniquely  identified.  Consequently, 
all  occurrences  can  be  identified.  Also,  only  one  assignment  of 
numerical  values  need  be  ready,  the  assignment  can  be  as  "late" 
as  possible,  and  sensitivity-analysis  can  be  carried  out. 
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SYSTEK-PAPAME'"EP 

A S YSTEm-PA  R AME'^E?  is  used  to  represent  a value  relevant  to 
cha ract eriz i na  "system"  size.  A SYSTEM-PARAMETER  may  be  used  to 
describe  the  number  of  instances  of  a particular  ELEMENT  in  a 
particular  instance  of  an  ENTITY,  for  example. 


INTERVAL 

An  INTERVAL  is  used  to  describe  a unit  of  time.  In  defining 
frequency  of  an  occurrence  in  the  system,  the  frequency  must  be 
defined  with  respect  to  some  unit  of  time.  A "year"  is  an 
example  of  an  interval,  as  is  "work  week." 


1.3.  3.7  Dyna mic  Behavior 

The  description  of  the  dynamic  behavior  of  the  system  indicates 
requirements  on  processing  order  and  the  relationships  between 
processes  and  ob-iects  that  initiate,  terminate,  or  interrupt 
them. 


EVENT 

An  EVENT  is  used  to  describe  possible  occurrences  during  the 
ooeration  of  the  target  system.  An  occurrence  of  an  EVENT  is 
associated  with  a specific  point  in  time,  but  the  same  EVENT  may 
occur  more  than  once  during  target  system  operation.  For 
example,  "error  recognized"  may  be  an  EVENT  that  causes  normal 
processing  to  be  suspended  while  an  error  processor  is 
initiated. 


CONDITION 

A CONDITION  is  used  to  describe  some  aspect  of  the  state  of  the 
target  system.  A CONDITION  may  be  either  true  or  false.  For 
example,  "input  data  valid"  could  be  a CONDITION.  A change  of 
this  CONDITION  from  true  to  false  might  cause  an  EVENT  (such  as 
"error  recognized")  or  might  directly  initiate  error  processing. 


1.3.3.P  System  Architecture  Ob  iects 


PROCESSOR 

An  object  that  can  "perform"  a PROCESS  is  a PROCESSOR,  In  other 
words,  a PROCESSOR  is  an  "agent"  that  physically  acts  to  perform 
a PROCESS.  A computer  system,  a department  in  an  organization, 
a person,  can  all  be  modeled  as  a PROCESSOR. 
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The  tot  Hi  tHU'jet  system  can  be  regarded  as  being  performed  by  a 
single  PROCESSOR  at  the  highest  level.  This  highest  level 
PPOCESSCR  is  '■he  collection  of  all  the  physical  entities 
(including  human  beings)  that  actually  carries  out  all  the 
information  processing  functions  in  the  system. 


PTS roRCE 

FESOflFC^  is  something  that  the  physical  elements  in  the  target 
system  consume  in  order  to  carry  out  information  processing 
functions.  A PESOUFCE  is  consumed  , and  once  an  amount  of 
RESOURCE  is  consumed,  it  is  considered  unrecoverable  because  it 
is  "used  up."  For  example,  a certain  amount  of  PESOUPTE  called 
electricity  is  consumed  by  an  electrical  appliance  in  a given 
time  period.  The  amount  of  electricity  thus  consumed  is  not 
recoverable  because  it  is  used  up. 

It  is  important  to  note  this  somewhat  specialized  meaning  of 
RESOPECE.  In  the  general  usage  of  the  term,  "resource"  could 
mean  something  that  is  needed  for  a task  to  be  performed,  but 
which  is  re  turned  after  it  is  finished.  For  example,  an 
electrical  appliance  can  be  regarded  as  a resource  in  this 
sense:  when  it  is  being  used  by  someone,  nobody  else  can  use  it; 
but  when  it  is  no  longer  used,  it  is  available  for  use.  In  URL 
•■his  secon-l  meaning  of  "resource"  is  modeled  by  PROCESSOR,  and 
the  terra  RESOURCE  is  exclusively  used  for  the  first  meaning. 


UMIT 

Since  it  is  necessary  to  handle  quantities  of  RESOURCES,  units 
are  needed  to  measure  RESOURCES.  The  object  UNIT  is  used  for 
'■his  purpose.  A UNIT  is  used  to  measure  RESOURCES.  For 
example,  electricity  may  be  measured  in  a UNIT  called 
"ki lowatt-hour.  " 


RESCUPCS-USAgE-PAEA METER 

A RESOURCE- USAGE-PARAMETER  is  an  object  that  defines  a measure 
of  bhe  RESOURCE  usage  for  a PROCESS.  It  is  introduced  in  URL  as 
a way  of  expressing  resource  consumption  of  a PROCESSOR 
performing  a PP0C'=’SS  independent  of  what  PROCESSOR  performs  it. 

For  example,  one  can  assign  values  for  a RESOURCE-USAGE- 
PARAM'^TER  " n o-o  f-f  0 r t ran-st  eps  " to  a set  of  PFOCESSes.  The 
values  of  the  R ESOU RCE-USAG E-P ARAMETEF  for  a PROCESS  might 
signify  the  number  of  FORTRAN  steps  if  the  PROCESS  is  to  be 
performed  by  a computer  and  FORTRAN  is  to  be  used  to  write  the 
program.  The  actual  amount  of  RESOURCE  consumed  in  order  to 
carry  out  this  PROCESS  depends  on  the  particular  PROCESSOR'S 
ability,  which  is  expressed  in  terms  of  RESOURCE  consumption  per 
RESOURCE-US AGE-PAPA  METER . 
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1.3.4  Project  Managejjent  Ob  jects 

Project  nunaqement  objects  are  used  to  provide  information  about 
the  individual  writing  the  URL  description  of  the  target  system. 
URL  is  not  intended  to  be  a oroject  Banagement  systea,  but  it 
provides  for  two  types  of  objects. 


PROBLEW-DEF INEB 

PPOBIEK-DEFINER  is  an  object  used  to  describe  a person  who 
writes  the  problem  statement  (URL  statements)  for  the  target 
system  or  who  has  the  responsibility  of  maintaining  the  URL 
descriptions  for  one  or  more  other  URL  objects.  For  example, 
PROBLEE-DEFINSR , "Jane  Smith,"  may  be  responsible  for  the  URL 
description  of  the  objects,  "employee  information,"  "payroll 
processing,"  etc.,  while  other  people  on  the  project  may  be 
responsible  for  other  objects  in  the  target  system's 
description . 


yiAILEOX 

A MAILBOX  is  used  to  describe  the  location  where  questions 
and/or  information  about  the  URL  description  of  a particular 
target  system  may  be  sent.  Usually  a MAILBOX  is  related  to  a 
PROBLEM-DEFINER  . 


1.3.5  Property  Objects 


For  an  accurate  description  of  a target  system,  special 
oroperties  of  certain  objects  must  be  defined.  For  example,  in 
describing  a large  information  processing  system,  it  may  be 
necessary  to  define  which  functions  (PROCESSES)  ace  to  be  done 
manually,  run  batch,  or  on-line,  etc.  The  URL  object  types  that 
are  available  are  SYNONYM,  KEYWORD,  ATTRIBUTE,  ATTRIBUTE- VALUE, 
CLASSIFICATION,  MEMO,  SOURCE,  SECURITY  and  TRACE-KEY. 


SYNCNYH 


A SYNONYM  is  used 
given  name  in  the 
may  simply  define 
totally  different 
the  object  (i.e., 
but  call  it  severa 


to  define  an  alternative  name  (alias)  for  a 
URL  description  of  the  system.  The  SYNONYM 
an  abbreviation  of  a long  name  or  spscify  a 
name  for  an  object,  depending  on  who  looks 
several  people  may  think  of  the  same  thing, 
1 different  names)  . 


at 


KEYWORD 

A KEYWORD  is  an  object  type  used  to  identify  one  or  more  objects 
in  the  target  system  description  for  selection  and  analysis 
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purposps.  For  example,  if  all  twncfions  (PROCESSES)  described 
as  beinq  manual  procedures  in  the  target  system  were  to  be 
listed  and  analyzed  together,  the  KEYWORD  ’’manual'*  could  be 
attached  to  each  PROCESS  for  this  purpose. 


aTTRiRTTrs  an_l  A TTRT  BtP’E-VAL  UE 

AFTRIBUTES  and  ATTRIBUTE-VALUES  are  used  to  describe 
characteristics  of  particular  ohiects  in  the  target  system 
description  that  may  not  be  described  by  any  other  URL 
statements,  '='or  example,  to  describe  that  the  length  of  an 
ELEMENT  is  six  characters  long,  the  ATTRIBUTE  "length”  could  be 
defired  and,  for  a particular  ELEMENT,  the  corresponding 
AT-^PIBUTE-V  ALUE  could  he  "6  . " 


CLA  SSIFICmTION 


CLASSIFICATION  may  be  associated  with  data  ohiects,  PROCESSES 
and  PROCESSORS  in  the  target  system.  A value  may  also  be 
associated  with  the  CLASSIFICATION.  In  order  for  a PROCESS  or 
P'^OCESSOR  to  he  allowed  access  in  the  target  system  to  a data 
obiect,  it  must  have  all  the  CLASSIFICATIONS  that  are  associated 
with  the  data  object,  and  the  value  must  he  greater  than  or 
eoual  to  the  value  associated  with  the  data  object. 


M M c 

A memo  is  use)  to  describe  a note  (text)  relevant  to  some  aspect 
of  the  target  system  description.  For  example,  a note 
concerning  unresolved  problems  in  describing  a select  number  of 
CROtiPS  in  the  target  system  description  could  be  defined  as  a 
EEMO  and  then  related  to  each  of  the  appropriate  3P0UPS. 


SOU’^CE 

A SOUPcr  is  used  to  describe  an  object,  outsidi?  of  the  problem 
'♦■atemen’-,  relevant  to  the  description  of  one  or  more  objects  in 
the  target  system  description.  For  example,  a feasibility  study 
of  the  target  system  being  designed  may  have  information 
relevant  to  whv  one  alternative  of  describing  the  target  system 
was  chosen  over  another.  The  feasibility  study  could  be 
desicnatad  as  an  object  of  type  SCUFCE. 


RECnpI-^Y 


3ECUFITY  is  us'^'d  to  identify  what  objec'  descrip’’ ions  can  be 
reviewed  hv  a given  class  of  persons.  Some  types  of  information 
maintained  by  the  target  system  may  he  considered  confidential, 
so  the  descrin'-ion  in  the  problem  statemfn*  on  how  this 
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information  is  maintained  may  be  restricted  to  hi<}h  level 
management  and  a few  select  programmers. 

TRACE-KEY 

A TRACE-KEY  is  usel  to  correlate  objects  which  exist  in 
different  data-bases.  For  example,  the  logical  system  design 
and  physical  sys’-em  design  of  a security  control  system  may 
exist  in  two  different  data-bases.  An  object  called  a security 
level  may  exist  in  the  logical  design  data-base,  and  a field  of 
numbers  called  a security  level  number  may  exist  in  the  physical 
design  data-base.  A TRACE-KEY  called  a security  level  may 

be  applied  to  both  objects  to  display  the  correlation  between 
them . 


1 . U URL  Relationshi ps 

The  previous  section  presented  the  types  of  objects  that  must  be 
defined  when  describing  an  information  processing  system. 
Organization  objects  define  the  environment  in  which  the  target 
system  is  embedded.  Target  System  objects  describe  the 
components  of  the  target  system.  Project  Management  objects 
describe  the  project  in  which  the  target  system  is  being 
developed,  and  Property  objects  describe  properties  of  all  tyoes 
of  objects. 

In  addition  to  identifying  particular  objects  (by  giving  them 
names),  the  relationships  among  these  objects  must  be  stated. 

For  example,  if  "employee-information"  is  defined  to  be  an  input 
and  "payroll-processing"  as  a PROCESS,  a relationship  connecting 
these  two  objects  may  be  specified.  In  URL  terminology,  if 
"emoloyee- inf or raati on"  is  an  input  to  "payroll-processing,"  the 
relationship  can  be  stated  "payroll-processing"  RECEIVES 
"employee- infor mati on"  or  "employee-information"  is  RECEIVED  by 
"oayrol 1- processing  . " 

Figure  1.4.1  presents  a listing  of  all  relationships  allowed  in 
URL  in  alphabetical  order  along  with  legal  abbreviations  for 
these  statements.  (A  dash  in  place  of  an  abbreviation 
designates  that  there  is  no  acceptable  abbreviation  for  that 
statement.)  This  section  gives  an  introduction  to  the 
relationships.  They  are  defined  in  detail  in  Section  2 and  3. 


1.4.1  Complementarity 

One  characteristic  of  most  relationships  between  two  names  is 
that  it  may  be  specified  in  both  directions.  For  example, 
specifying  that  an  OUTPUT  is  GENERATED  by  a PROCESS  is 
euuivalent  to  specifying  that  the  PROCESS  GENERATES  the  OUTPUT. 
GENERATED  and  GENERATES  are  called  complementary  relationships. 
Figure  1.4.2  presents  a list  of  all  complenGntary  relationship 
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P’lirs.  (A  dash  df'siqnates  that  the  relationship  does  not  have  a 
complement . ) 

1.U.2  Felat  ionshins  ^tw^n  Pi  f ferent  C lasses  of  Ob  j.ect  s 

UFi.  allows  a namher  of  relationships  to  "connect"  ob-jects 
whether  they  are  of  the  same  class  as  defined  in  Section  1.3  or 
in  different  classes.  For  instance,  in  the  above  example,  two 
Tarqet  System  objects  were  related  via  the  RECEIVES 
relationship.  Since  Orqanization  objects.  Project  Manaqemei.t, 
and  Property  objects  also  contribute  to  the  description  of  the 
system,  they,  too,  must  be  related  to  defined  Tarqet  System 
objects.  Therefore,  there  is  another  set  of  relati  onsh  ’ os  to 
connect  Tarqet  System  objects  with  Organization  objects,  another 
for  Tarqet  System  objects  ani  Property  objects,  etc.  "lie 
possible  sets  of  relationships  are  shown  in  Figure  1.4.3. 

Relationships  may  be  classified  in  the  same  way  as  objects  were 
classified  in  Section  1.3.  The  first  row  of  Fiqure  1.4.3 
presents  relationships  that  an  Organization  object  may  have  with 
other  Organization  objects,  with  Target  System  objects.  Project 
''anaqement  objects  and  Property  objects.  The  second  row 
oresents  relationships  that  a Target  System  object  may  have  with 
Orqanization  objects,  other  Target  System  objects.  Project 
Management  objects  and  Property  objects.  The  third  row  presents 
relationships  that  a Project  Management  object  may  have  with 
Organization  objects,  Targer  System  objects,  other  Project 
''ar.aqement  objects,  and  Property  objects.  The  fourth  row  in 
■^iqure  1.4.3  presents  relationships  that  a Property  object  may 
have  with  Organization  objects,  Tarjot  System  objects.  Project 
Management  objects  and  other  Property'  objects. 
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Abhre- 

A hbre- 

Relationship 

vi a tion 

Relationship 

V iat ion 

APPLIES 

APP 

PROCEDURE 

PRCD 

ASS  EFT 

ASRT 

RECEIVED 

RCVD 

ASSOCIA'^ED 

ASOC 

RECEIVES 

RCVS 

ASSOCIATED- DATA 

ASOD 

RELATED 

REL 

ATTRIBUTES 

ATTR 

RESOURCE-USAGE 

RU 

BETWEEN 

BTWN 

RESOURCE- US  AGE- PAR  A ME  TER-  VALU 

S PUPV 

CAP  DINA  LITY 

CARD 

RESPONSIBLE 

PESP 

CAUSED 

CSD 

RESPONSIBLE- INTER  FACE 

PINT 

CAUSES 

CSS 

RESPONSTBLE-PROBLEM-DEFIN  ES 

RPD 

CLASSIFICATION 

CLS 

S ECURITY 

SEC 

CON  NFCTIVITY 

CONN 

SECUPITY-ACCESS-R IGHTS 

SAD 

CONSISTS 

CSTS 

SEE-.MEMO 

SM 

CON  SUMFD 

CNSD 

SOU5CE 

SPC 

CONSUMES 

CNSS 

SUBP APTS 

SUBP 

CONTAINED 

CNTD 

SUBSET 

S3T 

DERIVATION 

DPVN 

SUBSETS 

SSTS 

DEP IVED 

DFVD 

SUBSETTING-CRITEPIA 

SSCA 

DEP IVES 

DFVS 

SUBSETTTNG-CR ITER TON 

SSCN 

DESCEIPTION 

DISC 

SYNONYM 

SYN 

GEN  FPATED 

GEND 

TERMINATED 

TRMD 

GEN  PRATES 

GENS 

TERMINATES 

TRE3 

HAPPENS 

HAP 

TERMINATION 

TE  PM 

IDENTIFIED 

TDD 

TERMINATION-CAUSES 

TEPC 

IOFN"'IFIES 

IDS 

TRIGGERED 

TRGD 

INC  EPTION 

INCP 

TRIGGERS 

TRGS 

INCEPTION-CAUSES 

INCC 

UPDATED 

UPDD 

tnterrupted 

INTD 

UPDATES 

OPDS 

INTERRUPTS 

INTS 

USED 

— 

KEYWORD 

KEY 

USES 

— 

MADE 

— 

UTILIZED 

UTLD 

MAKES 

MAK 

UTILIZES 

UTLS 

MAILEOX 

BOX 

V ALHES 

VAI 

MAINTAINED 

MNTD 

VOLATILITY 

VOL 

MAINTAINS 

MNTS 

VOLATILITY-MEMBER 

VOLM 

MEASURED 

MSRD 

VOLATILITY-SET 

VOIS 

MEASURES 

HSRS 

WHILE 

WHL 

DART 

— 

PERFORMED 

PPMD 

PEP  FORM  S 

PPMS 

Fiuure  1.4.1 

List  of  URL  Statements 

in  Alphabetical  Orvler  with  Abbreviations 
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Relationshi p 

ASSER1' 

ASSOCTA  TFD 
ATTRIBUTES 
CAR  DINA  LI'"Y 
CAUSED 

CONNECTIVITY 

CONSUMED 

CON  TAIN  ED 

DERIVED 

GENERATED 

HAPPENS 

IDENTIFIED 

INCEPTION 

INTERRUPTED 

KEYWORD 

MADE 

MATLPCX 

MAINTAINED 

MEASURED 

PART 

PERFORMED 

RECEIVED 

RELATED 

PESOOPCE-US  AGE 

RESPONSIBLE- IN?  EFFACE 

RESPONSIBLE-PFDBLEM-DEFINEP 

SECURITY 

SEE- MEMO 

SOURCE 

SUBSET 

SUBSF"’TING-CRI'"  ERIA 

SYN  INYF 

TERMINATED 

"^EP  M INA  TION 

'^RACF-KFY 

TRIGGERED 

UPDATED 

USED 

UTILISED 

VALUES 


Complementary  Relationship 


ASSOCIATED-DATA 


CAUSES 

CONSUMES 

CONSISTS 

DERIVES 

GENERATES 

IDENTIFIES 

INCEPTION-CAUSES 

INTERRUPTES 

APPLIES 

MAKES 

APPLIES 

MAINTAINS 

MEASURES 

SDBPAETS 

PERFORM  S 

RECEIVES 

BETWEEN 

PESOURCE-US  AGE- PARA  METER- VALUE 

RESPONSIBLE 

RESPONS IBLE 

APPLIES 

APPLIES 

APPLIES 

SUBSETS 

SUBSETTING-CRITERION 

DESIGNATE 

TERMINATES 

TERMINATION-CAUSES 

APPLIES 

TRIGGERS 

UPDATES 

OSES 

UTILIZES 


Figure  1.4.2 

List  of  all  URL  Relationships  with  Complementary  Relationships 
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OPG  ANIZ  A'^'ION  OBJECTS 


TARGET  SYSTEM  OBJECTS 


organization 

OBJECTS 


■''ARGFT 

SYSTEM 

OBJECTS 


SUBPARTS/PAPT 


GENERATED 

RECEIVED 

RES  PONS IBL  E- INTER FACE 


GENERATES 

RESPONSIBLE 

RECEIVES 


ASSOCIATED/ 

A SSOCIATED-DA 
CARDINALITY 
CAUSED/CAUSES 
CLASSIFICATION 
CONNECTIVITY 
CONSUMED/CONSU 
CONTAINED/CONC 
DEPIVFD/DEPIVE 
GENEPATED/GENF 
HAPPENS 

IDENTIFIED/IDE 
INCEPTION/ 
INCEPTION-CAU 
INTERRUPTED/IN 
MADE/MA  XES 
MAINTAINED/MAI 
MEASU’^ED/MEASU 
PART/S U BPA  RT 
PEPFOPMED/PERF 
RECEIVED/RECEI 
°ELATED/RSLATF 
PESOURCE-US AGE 
RESOURCE- USAS 
PARAMETER-VAL 
SECURITY-ACCES 
SIIBSET/SUDSETS 
SUBSETTING-CPI 
SU  BSETTI  NG-C 
TERMINATED/TEF, 
TERMINATION/ 
TERMINAIION- 
I’RIGGEPED/TR  IG 
UPDATED/UPDATE 

utilized/util: 

VALUES 


"ES 
I S TS 
S 

RATES 
NT IFIE  S 
SES 

■■^EERUPTS 

NTAINS 

SES 

OPMS 

VES 

S 

/ 

UE 

S-  RIGHT‘S 

TERI  A/ 
PITERION 
MI  NATES 

CAUSES 
;f  RS 


PROJECT 

RESPONSIBLE 

RESPONSIBLE 

MANAGEMENT 

OBJECTS 

ppo  p£p'^  y 
OBJECTS 

A'’PLI'='S 

APPLIES 

Figure  1 . 3 Relationships  among  classes  of  Ob-jec*- 
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PROJECT  MANAGEMENT  OBJECTS 

PPOPERTjf  O^ECTS 

ORG  ANT7 ATIQN 
Q3JFCTS 

PESPONSIBL  E- P RO BL EM- DE FINER 

ATTRIBUTES 

KEYWORDS 

SECURITY 

SEE-MEMD 

SOURCE 

SYNONYM 

TRACE-  KE  Y 

TAPOF'" 

SYSTEM 

OBJECTS 

RES  PONSIBL  E-PROBLEM-DE FINER 

ATTRIBUTES 

KEYWORDS 

SECURITY 

S EE-MEMQ 

SOURCE 

SYNONYM 

TRACE-KF  Y 

PROJECT 

MANAGEMENT 

OBJECTS 

MA ILBOX/APPLIES 

ATTRIBUTES 

KEYWORDS 

SECURITY 

S EE-MEMO 

SOURCE 

SYNONYM 

TRACE- KEY 

PROPERTY 

OBJECTS 

APPLIES 

ATTRIBUTES 
KEYWORDS /A  PPLIES 
SECURITY /APPLIES 
SEE-MEHO/APPLIES 
SOURCE/A  PPLIES 
SYNONYM 

TRACE-KEY 

Fiqure  1.4,3  Relationships  among  Classes  of  Objects 

(Continued) 
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1.4.3  Narrat ivp  and  Text  Descr ipt ion 

Any  information  which  is  needed  to  describe  an  object  and  which 
cannot  be  specified  bv  using  one  or  more  relationships  can  be 
specified  in  a narrative  or  text  description  called  a comment 
entry.  These  comment  entries  are  not  named  (as  objects  are 
name)  and,  therefore,  apply  to  only  one  particular  name.  A 
number  of  different  types  of  comment  entries  may  be  defined 
depending  on  the  type  of  object  they  pertain  to.  The  tyoes  of 
narrative  and  free-format  descriptions  that  may  be  defined  in 
U'^L  according  to  the  class  of  objects  being  described  is  given 
in  Figure  1.4.5. 


1.4.4  Classif icatio  n of  Pelat ionshjps  by  System  Aspects 

The  relationships  may  be  grouped  into  nine  major  groups  on  the 
basis  of  the  "aspect"  of  the  system  which  they  describe.  These 
nine  major  aspects  are: 

System  Flow 
System  Structure 
Data  Structure 
Data  Derivation 
System  Si^e  and  Volume 
System  Dynamics 
System  Architecture 
System  Properties 
Project  Management 

Each  is  defined  below.  Specifying  information  about  each  of 
these  aspects  involves  one- or  more  object  types  and 
relationships.  Figure  1.4.6  presents  a summary  of  these  nine 
aspects  with  corresponding  objects  and  relationships. 


1.4. 4.1  System  Flow 

The  System  Flow  aspect  of  the  system  deals  with  the  interaction 
between  the  target  system  and  its  environment.  This  involves 
describing  those  objects  (INPUTS)  which  are  supplied  by  the 
environment  (INTEPFACFS)  to  the  target  system,  those  objects 
(OUTPUTS)  which  are  produced  by  the  target  system  and  accepted 
by  the  environment,  and  the  responsibility  of  the  environment 
for  information  (SETS)  within  the  system. 

Any  transfers  of  data  within  the  system  are  not  considered  as 
part  of  System  Flow  because  there  is  no  interaction  with  the 
«^n  V iron  ment . 


1 . 4 . 4 . 2 t em  Structure 

System  Structure  is  concerned  with  the  hierarchies  inherent  in 
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Host  types  of  systems.  (This  includes  information  structures  as 
well  as  processing  structures.)  Structures  may  also  be 
intto^luced  to  facilitate  a particular  design  approach  such  as 
•’top  down."  In  this  context  all  information  may  initially  be 
grouped  together  and  called  by  one  name  at  the  highest  level, 
and  then  gradually  broken  down.  System  structures  can  represent 
high-level  hierarchies  which  may  not  actually  exist  in  the 
system  as  well  as  those  that  do. 


CLASS  OF  OBJ  EC’'  TYPES 

COMMENT  ENTRY  RELATIONSHIP 

ofgani7A”ton  objects 

DESCRIPTION 

TARGET  SYSTFM  OBJECTS 

DERIVATION 

DESCRIPTION 

PROCEDURE 

VOLATILITY 

VOLATILITY-MEMBER 

VOLATILITY-SET 

WHILE 

PROJECT  HAN’ .AO^M  ENT 
OBJECTS 

DESCRIPTION 

PROPERTY  OBJECTS 

DESCRIPTION 

Figure  1. 
for 

4.5  Types  of  Comment  Entries 
each  Class  of  Objects 
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SYSTEM  ASPEC'" 

UPL  OBJECTS 

URL  RELATIONSHIPS 

SYSTEM  FLOW 

INTERFACE 

INPUT 

OUTPUT 

PROCESS 

SET 

RECEIVES/RECEIVED 

GENERATES /GEN ERA!  ED 
UPDATES/UPDA.TED 

P ESPONSIBLE-INTEP  ’'ACE 

SYSTEM  STRUCTURE 

INTERFACE 

INPUT 

OUTPUT 

PROCESS 

SET 

SUBPARTS/PART  OF 

S UBSET/SUBSETS 
UTTLIZES/UTILI ZED 

DATA  STRUCTURE 

GROUP 

ELEMENT 

ENTITY 

CONSISTS/CONTAINED 

I D ENT  I F IE S / ID  E N TI  PI  ED 
SUBSETTING -CRITERIA/ 
SUBSET!  I NG-CR  IIEP  ION 
ASSOCTATED/ASSOCI ATED-DATA 

DATA  DERIVATION 

INTERFACE 

INPUT 

OUTPUT 

PROCESS 

SET 

GROUP 

ELEMENT 

ENTITY 

CLASSIFICATION 

USES/USED 

DERIVES/DERIVED 

UPDATES/UPDATED 

M AINTAINS/MAINTAI  NED 
PROCEDURE  * 

DERIVATION  * 

CLASSIFICATION 

SECURITY- ACCESS- 
RIGHTS 

SYSTEM  SIZE 

SYSTEM-PARAMETER 

INTERVAL 

CONSISTS 

HAPPENS 

CONNECTIVITY 

CARDINALITY 

VALUES 

VOLATILITY  * 

VOLATILITY-SET  * 
VOLATILITY-MEMBER  * 

SYSTEM  DYNAMICS 

EVENTS 

CONDITION 

CAUSES/CAUSED 

INCEPTION-CAUSES/ 

ON  INCEPTION 

INTERRUPTS /IN TERR  UP TED 
MAKES/MADE 

TEPMI  NATES/TERMINATED 
TERMINATION-CAUSES/ 

ON  TERMINATION 

T RIGGERS/T PIG  GERE D 

WHILE  ♦ 

* 


connpnt 


er  try 

Figure  1.4.6 

HPL  Dbiect  and  Statements  Organized  According 
to  Aspect  of  Target  System  Described 
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SYSTEF.  ASPECT 

URL  OBJECTS 

URL  RELAIIONSHIPS 

SYSTFM  ARCHITECTUPF 

PROCESSOR 

RFSOURCE 

RFSOURCE-USAGE- 

PARAMETER 

UNIT 

CONSUME S/CONS UHED 
PEFOBMS/PEEFOFMED 
BESOURCE- USA3E/ 
RESOURCE-USAGE- 
PARAMETER-VALUE 
HEASURES/MEASURED 

PROJECT  MANAGEMENT 

PFOBLBM-DEFINER 

MAILBOX 

RESPONSIBLE/ 

RESPONSIBLE- 

PBOBLEM-DEFINEF, 

MAILBOX/APPLIES 

PROPERTIES 

ATTRIBUTE/ 

ATTRI BUTE-VALUE 
CLASSIFICATION 
KEYWORD 

MEMO 

SYNONYM 

SOURCE 

SECURITY 

TP  ACE-K  EY 

ATTPIBUTES/APPLIE  S 

KEYWORDS/APPLIES 

SEE-MSMO/APPLIES 

SYNONYMS/DESIGNATB 

DESCRIPTION  * 

SOURCE/APPLIES 

SECURITY/APPLIES 

TRACE- KEY /APPLIES 

ASSERT 

* coBment:  entry 


Figure  1.4.6 
URL  Object  and  Statenen 
to  Aspect  of  Target 


(Conti nued) 

ts  Organized  According 
Systea  Described 
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1.4.U.3  ^ta  ?;t  ruct  ure 

Oat.a  Structures  represent  the  relationships  that  exist  among 
(lata  used  and/or  manipulated  by  the  system  as  seen  by  the 
"users"  of  the  system.  Data  Structures  also  exist  in  the  way 
data  is  grouped  in  collections  of  information  such  as  documents. 
The  description  of  Data  Structures  also  involves  specification 
of  relationships  among  logical  collections  of  data  and  the  data 
associated  with  such  relationships. 


1.4. 4. 4  Data  Derivation 

The  Data  Derivation  aspect  of  the  system  description  specifies 
the  way  in  which  data  is  manipulated  or  derived  by  the  system. 

It  specifies  what  information  is  used,  updated  and/or  derived, 
how  this  is  dona,  and  by  which  processes.  This  aspect  differs 
from  System  Flow,  since  System  Flow  only  designates  the  inputs 
to  th  system  and  the  end  results  (OUTPUTS),  without  specifying 
what  actions  take  place  to  bring  these  transformations  about. 
Data  Derivation  can  deal  with  the  very  lowest  transformations  of 
data,  whereas.  System  Flow  deals  with  high  level  collections  of 
infcrmation  (i.e.,  lUPUTS  and  OUTPUTS). 


1 . 4 . 4 . 5  Syst  em  Size 


The  System  Size  is  concerned  with  the  size  of  the  system  and 
those  factors  that  influence  the  volume  of  orocessing  that  will 
be  required.  To  describe  system  size,  the  parameters  involved 
are  named  as  objects. 


1.4. 4.6  ^stem  Dyna  mics 

The  dynamic  analysis  aspect  of  system  description  presents  the 
manner  in  which  the  target  system  behaves  over  time.  EVENTS  and 
CONDITIONS  are  used  to  help  lescribe  when  PROCESSES  are 
performed  and  under  what  conditions. 

1 . 4 . 4 . 7 S js^^  Arch  i tect  ure 

The  System  Architecture  aspect  deals  with  the  physical 
components  and  structures  that  are  necessary  in  order  to  realize 
the  given  user  requirements. 


1.4.4.S  Pro  i ect  "an  aaejSent  - 

In  addition  to  the  description  of  the  ‘•arget  system  being 
designed,  documentation  of  the  group  designing  (or  docum^ntim) 
the  target  svstem  is  needed.  This  involves  identification  of 
perscns  involve)  and  their  responsibilities,  etc. 
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1.4. 4. 9 Propert  ies 

All  oblects  (of  a particular  type)  used  to  describe  the  target 
systen  have  characteristics  that  distinguish  then  froB  other 
obiects  of  the  same  type.  Therefore,  the  properties  of 
particular  obiects  in  the  system  must  be  described.  In  general, 
Properties  involve  any  description  particular  to  a given  object. 


1 . S System  Docu  went  ation  Using  UPI/URA 

The  Process  of  using  UBL/URA  to  describe  an  information 
processing  system  includes  the  following  steps; 

1)  Gathering  information  about  the  system. 

2)  Expressing  the  information  in  URL. 

3)  Formatting  URL  as  required  by  URA. 

4)  Converting  the  Problem  Statement  into  computer  processable 
form. 

5)  Entering  the  data  into  the  project  data-base. 

6)  Generating  outputs  from  the  data-base. 


1.5.1  Gathering  Inf  orma tjon  About  the  S vstem 

This  step  can  be  carried  out  as  with  present  manual  methods. 
However,  the  URL  structure  (sections  and  statements)  can  be  used 
as  a structure  for  which  information  is  collected.  URA  outputs 
can  also  be  used  as  a checklist  of  missing  information. 


1.5.2  E xpressin  g the  Information  in  URL 
The  use  of  URL  consists  of; 

- Identifying  obiects,  naming  them  and  assigning  a unique  type 
to  each. 

- Determining  the  relationships  among  the  objects. 

- Rtating  appropriate  properties  for  each  object. 

Any  information  which  cannot  be  expressed  in  this  formal  syntax 
can  be  given  as  text  in  comment  entries. 

1.5.3  Forma t ting  UR L as  Reg uired  by  URA 

URA  requires  only  minimal  formatting  as  described  in  Section 
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1.5.4  Converting  the  Problem  Statement  into  Computer  Processa M e 
Form 

The  problem  statement  can  be  read  by  URA  from  whatever  form  of 
computer  processahle  input  is  desired.  The  usual  procedure  will 
he  to  punch  the  problem  on  cards  or  to  enter  it  via  a terminal. 

The  data  can  be  entered  on  cards  anywhere  in  the  first  72 
columns. 

When  da'-a  is  entered  via  a terminal,  it  will  normally  first  be 
entered  into  a file. 


1.5.5  Entry  of  the  Rata  into  t]^  Proiec t Data  Base 

In  ISDOS  terminology,  the  description  of  a proposed  Information 
Processing  System  is  called  a Problem  Statement  in  the  sense 
that  it  represents  a "problem*'  to  be  solved.  The  physical 
system  designer  then  has  the  problem  of  finding  the  best  system 
to  accomplish  the  requirements  implicit  in  the  description  of 
the  proposed  Information  Processing  System.  (The  proposed 
system  can  bo  considered  a solution  to  an  earlier  problem, 
namely,  the  problem  of  what  outputs  are  necessary  to  satisfy  the 
"users"  needs  for  information.)  The  URA  data-base  contains  the 
problem  statement  as  it  has  been  given  up  to  that  time. 

The  problem  statement  will  he  built  up  over  a period  of  time, 
possibly  by  a nurobei  of  problem  definers  working  simultaneously. 
Three  aspects  of  a problem  statement  and  its  use  during  logical 
system  design  need  to  be  considered: 

1)  The  documentation  of  the  problem  statement  available  to  the 
problem  definer  based  on  the  URL  information  in  the 
data-base. 

2)  The  problem  statement  as  it  exists  in  the  data-base. 

The  data-base  con'-ains  information  about  all  the  objects  that 
have  been  identified,  and  all  the  relationships  among  those 
objects  that  have  been  specified.  It  also  contains  narrative 
statements  to  b«»  used  in  the  final  documentation.  Except  for 
the  narrative  statements,  the  data  is  stored  in  "coded"  form  and 
not  as  a copy  of  the  FORMATTED  PROBLEM  STATEMENT. 

3)  The  method  by  which  the  problem  statement  is  added  to  or 
modified. 

When  the  problem  definer  wishes  to  add  to  the  data-base  or 
modify  it  in  some  way,  input  is  prepared  according  to  the  syntax 
of  URL,  i.e.,  in  the  same  form  as  the  FORMATTED  PROBLEM 
STATEMENT.  However,  only  new  data  or  changes  to  the  data  need 
to  be  entered.  Any  data  not  affected  by  the  input  will  remain 
unchanged. 
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The  use  of  UPL,  therefore,  differs  froH  present  aethods  in  two 
significant  ways:  the  information  about  a proposed  system  can  be 
entered  in  any  order  and  only  new  data  or  changes  need  be 
entered . 


1 . 5 . f Generatin g Ou t puts  from  the  Data  Base 

At  any  time  problem  definers  can  obtain  outputs  based  on  all  or 
part  of  the  data  in  the  data-base.  These  outputs  would  be  used 
by  the  problem  definers  in  their  own  work  (Data  Collection, 
Analysis,  Design,  Evaluation  or  Improvement)  or  in  conferring 
with  users  and  others.  The  complete  statement  containing  all 
the  data  in  the  data-base  is  called  the  FORMATTED  PROBLEM 
STATEMENT.  The  other  outputs  contain  subsets  of  the  total 
documentation,  summaries,  rearrangements  and  analyses.  The  DEA 
User's  Manual  gives  a complete  description  of  each  report 
available  to  the  problem  definer. 

The  FORMATTED  PROBLEM  STATEMENT  is  based  on  all  the  data  in  the 
data-base.  It  is  not  merely  a listing  of  the  data  that  has  been 
entered  but  includes,  in  addition  to  the  relationships 
explicitly  stated,  those  that  have  been  implied  (i.e., 
complementary  relationships).  The  FORMATTED  PROBLEM  STATEMENT 
is  "syntactically"  correct,  i.e.,  it  can  be  processed  by  URA. 

In  practice  problem  definers  would  use  the  FORMATTED  PROBLEM 
STATEMENT  in  conjunction  with  ether  reports  from  URA. 


1.6  User  Requirements  Language:  Syntax  Structure 

Since  URL  is  a language  which  must  be  understood  by  a computer 
nroqram,  (URA),  it  must  have  a formal  structure,  usually 
referred  to  as  syntax.  in  this  section,  the  syntax  structure  of 
URL  is  outlined.  A more  datailed  statement  of  the  syntax  for 
UPL  appears  in  "User  Requirements  Language,  Language  Reference 
Manual . "* 


1.6.1  Language  Structure 

URL  consists  of  several  levels: 

jJEi  Descri ption  Constitutents 

Target  system  Description 
URL  Section 
URL  Statements 

Raserved  Words,  Names,  Numbers 
Ch  aracters 

each  level  consists  of  one  or  more  units  of  the 
document. 


I USER  REQUIREMENTS  LANGUAGE  MANUAL 


rP'*360/370/VS/TSO  UPL  OSEF'S  MANUAL 


37 


3ucc€edinq  l«:?vels.  A systam  description  consists  of  one  or  more 
URL  sections,  A URL  section  consists  of  one  or  more  UPL 
statements.  Each  UPL  statement  is  formed  by  some  combination  of 
Reserved  Words,  Names,  and/or  Numbers.  Finally,  the  Reserved 
Words,  Names  and  Numbers  consist  of  characters  allowed  by  the 
URL  character  set. 

The  syntax  of  the  constituents  at  each  level  are  define i in  the 
remainder  of  this  section. 


1.6.2  Problem  Statement  Format 

URL  is  a free-format  languaqe  in  contrast  to  "f  ixed-for  ma  t”  or 
"tabular."  In  particular,  this  means  that  URL  descriptions  can 
appear  anywhere  on  the  physical  medium,  such  as  punched  cards 
and  that  within  fairly  wide  limits,  information  can  be  entered 
in  any  order. 

The  program  which  "reads"  the  Problem  Description  understands  or 
decodes  the  descriotions  by  reorganizing  a delimiter  the 
semi-colon  (;)  and  Reserved  Words.  The  latter  are  defined  in 

1.6.6. 

The  ma-jor  advantages  of  free  format  are  that  complex  problem 
statements  can  be  made  with  relative  ease  and  the  problem 
statements  can  be  made  fairly  concise. 

Forms  can  be  designed  if  a more  structured  method  of  recording 
the  problem  statement  is  required.  One  possible  organization  of 
the  forms  is  given  in  Section  3. 

1.6.3  T arqet  System  Identif ication 

Only  one  UR  A data-base  is  needed  to  store  all  information  about 
a given  System.  This  data-base  represents  the  up-to-date 
version  of  the  system  description.  URA  has  facilities  for 
specifying  the  name  of  the  system  being  described  on  all  reports 
generated  from  the  data-base. 


1 . 6 . n£L  Sections 

A URL  description  or  Problem  Statement  consists  of  one  or  more 
URL  sections.  Each  section  consists  of  one  or  more  URL 
statements.  The  first  statement  in  a section  (and  the  only 
required  one)  is  called  the  Section  Header.  A Section  Header  is 
a URL  statement  that  identifies  a section  and  specifies; 

1)  That  the  user  defined  names  given  in  the  section  header  ace 
a particular  ob-ject  type  (e.g.,  PROCESS  or  SET,  etc.). 

2)  That  any  URL  statements  (up  to  the  next  Section  Header) 
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!irer;<»nt  soup  description  about  the  rame(s)  given  in  the 
header  and/or  fom  relationships  between  nanes  in  the 
headpr  and  other  user-defined  names  in  the  problem 
St  atem  ent . 


■"hpre  are  a finite  number  of  URL  statements  that  are  defined  as 
Section  Hpad^rs  and  ate  qiven  in  Table  1.6.4. 


CONDITIO': 

DFPIN’:’ 

rrsicNA'”'^ 

EL  EM ENT 

ENTITY 

EVFN"^ 

GROUP 

INPUT 

INTERFACE 

INTERVAL 


.MEMO 

OUTPUT 

PPOPLEM-DEFINER 

PROCESS 

PROCESSOR 

RELATION 

RESOURCE 

PESO URGE- US AGE- PAP  A METER 

SET 

UNIT 


Table  1.6.4.  Section  Header  Statements 


Most  ob-ject  types  are  defined  in  sections  of  the  same  time, 
i.e.,  a PROCESS  would  be  defined  in  the  PROCESS  section. 
Therefore,  th^re  is  a one  to  one  correspondence  between  types  of 
ob-jects  and  section  headers  except  that  the  following  types  of 
obiects  are  all  defined  in  a DEFINE  section: 


ATTRTRUTE 


SECURITY 


ATTRIBUTE- VALUE 
CLASSIFICATION 
KEYWORD 
MA ILDOX 


SOURCE 

SUBSETTING-CRITERION 
SYSTEM-PAP  AMETER 
TRACE-KEY 


and  a SYNONYM  is  assigned  to  an  object  by  a DESIGNATE  section. 
This  distinction  between  Type  of  Object  and  Section  Header  is 
immaterial  conceptually  and  is  introduced  only  to  simplify 
entering  URL  information  in'-o  the  data-base  since  all  the  Types 
of  Objects  described  in  a DEFINE  section  allow  essentially  the 
same  set  of  statements. 


For  each  type  of  section  header  there  are  a finite  number  of 
different  URL  statements  that  can  be  specified  after  it.  For 
example,  if  the  section  defines  a name  to  be  an  INPUT  it  may  be 
desirable  to  say  what  GENERATES  and  what  RECEIVES  the  INPUT,  but 
it  would  be  illogical  to  say  that  the  INPUT  MAINTAINS  other 
information.  Therefore,  there  are  a select  set  of  UHL 
statements  that  may  be  used  in  conjunction  with  a particular 
Section  Header.  The  Section  Summaries  in  Section  3 and  in  "User 
Reg uirements  Language,  Language  Reference  Manual,"*  present  a 
list  of  which  URL  statements  which  can  appear  in  each  type  of 
sec  t ion  . 


* Part  IT  0 f this  document. 
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1 . ^ . R URL  St  at^rient  s 

There  are  three  basic  types  of  URL  statements: 

1)  Section  Header  statement  - This  type  of  statement  is  used 
to  define  one  or  more  names  (objects)  to  be  a particular 
object  type  (e.g.,  PROCESS  or  GROUP)  as  described  ibove. 

2)  Relationship  statement  - This  type  of  statement  is  used  to 
specify  relationships  between  or  among  objects.  In 
specifying  tha  target  system  description,  it  is  necessary 
to  describe  which  INTERFACES  supply  which  INPUTS  to  which 
PROCESSES,  what  data  (GROUPS  and  ELEMENTS)  are  used  bv  what 
PROCESSES,  what  EVENTS  cause  which  PROCESSES  to  be 
triggered,  and  how  often,  etc.  For  each  type  of  object 
particular  relationships  can  be  specified  as  outlined  in 
1.U  and  described  in  more  detail  in  Section  2 and  3.  For 
example,  a relationship  between  an  OUTPUT  and  the  PROCESS 
which  produces  the  OUTPUT  would  be  specified  by  the 
GENERATES  statement.  A PROCESS  can  GENERATE  an  OUTPUT. 
Likewise,  an  OUTPUT  may  be  GENERATED  by  a PROCESS. 

3)  Comment  Entry  statement  - This  type  of  statement  is  used  to 
relate  a narrative  (or  text)  descrip'^ion  (comment  entry)  to 
a particular  object.  Text  descriptions,  therefore,  may  be 
used  to  supplement  relationships;  this  means  that  any 
information  which  cannot  be  directly  specified  in  one  or 
more  relationships  (relationship  statements)  can  be 
presented  in  a narrative  format. 

All  URL  statements  begin  with  a reserved  word  and  are  terminated 
bv  a semi-colon  (;)  . If  the  statement  specifies  a relationship 
(one  of  the  tvpes  of  statements  defined  previously)  then  the 
statement  must  also  consist  of  one  or  more  user  defined  names 
and  may  not  require  one  or  more  reserved  words.  Optional  words 
may  be  inserted  in  the  statements.  For  example: 

RECEIVED  BY  employee-processing; 

begins  with  the  reserved  words,  RECEIVED,  which  is  followed  by 
an  optional  word,  BY,  then  by  a user-defined  name, 
"employee-processing"  and  finally,  terminated  by  a semi-colon. 
Blanks  are  used  to  separate  words  and  names  in  the  statement. 

Any  number  of  blanks  may  be  used  where  one  blank  is  allowed. 

If  the  statement  is  a comment  entry  type  statement,  then  the 
first  line  of  the  statement  may  only  consist  of  reserved  words 
and  the  semi-colon.  Succeeding  lines  of  the  statement  are 
interpreted  as  the  comment  entry  text  until  a semi-colon  is 
encountered.  Therefore,  a semi-colon  may  not  be  used  in  the 
text  of  a comment  antrv  statement.  For  example: 

DFSCRIP'"ION; 

The  time  card  is  the  record  of  hours  an  hourly 
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eanloyep  worked  in  any  qiven  week.  ; 

knv  characters,  except  the  seni-colon,  mav  aopear  ir  the  lex'  - 
a comment  entry  such  as  the  period  (.)  in  this  ex..npie.  The 
comment  entry  text  may  not  begin  on  the  same  line  as  the 
reserved  word  for  the  statements. 

Tn  many  statements  which  specify  relationships  among  ob  g cr , ■ 

list  of  user  defined  names  may  be  given.  For  example; 

USES:  fica-tax,  federal-tax,  state- tax; 

designates  that  the  names  in  the  section  header,  to  which  t i 
statement  belongs,  USE  fica-tax,  federal-tax  and  state-t'  -. 
Blanks  may  be  used  on  either  side  of  the  commas  3^'parati^^g  t 
user  defined  names. 

Abbreviations  of  reserved  words  may  he  used  in  place  )f  the  i •• 
reserved  word.  For  example; 

RECEIVED  BY;  employee-processing; 

may  also  be  given  as; 

RCVD  employee-processing; 

"^he  allowable  abbreviations  (which  are  also  designated  as  being 
reserved  words)  are  given  in  Appendix  D of  "The  User’s 
Requirements  Language,  Language  Reference  Manual. 

1.^.6  Reser ved  Words,  Names  and  N umbers 

Reserved  words  are  combinations  of  letters  and  dashes  used  to 
identify  URL  section  headers,  URL  statements  and  optional  words, 
"^here  is  a limited  number  of  reserved  words  as  given  by  Appendix 
B of  "The  User's  requirements  Language,  Language  Reference 
Manual."!  All  reserved  words  are  defined  by  the  ORL/ORA  system 
and  may  not  be  changed  by  the  user. 

Optional  words  mav  be  used  by  the  problem  definer  to  improve  the 
readability  of  the  problem  statement.  Words  like  BY,  A,  ARE, 
*ND,  etc,  are  legal  URL  optional  words.  Appendix  C of  "The 
nser  Reguirements  Language,  Language  Reference  Manual"  is  a list 
of  all  URL  optional  words.  In  the  following  URL  statement; 

UBFD  BY  “tn  ploy  ee-processinq  TO  DERIVE  paycheck; 

the  words,  USED,  BY,  TO  and  DERIVE  are  URL  reserved  words. 

User  defined  names  are  any  names  (words)  used  in  a URL  statement 
that  are  not  URL  reserved  words.  Restrictions  on  user  defined 
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nases  are  that  thisy  may  only  begin  with  a letter,  consist  of 
only  letters,  digits  and  dashes,  and  be  no  longer  than  thirty 
characters  in  length.  The  names  "employee-processing"  and 
"paycheck"  in  the  previous  example  are  instances  of  user  defined 
names. 

Numbers  used  in  a UFL  statement  may  only  consist  of  the  digits  0 
through  9 with  no  decimal  points  plus  or  minus  signs,  etc., 
allowed . 

1.6.7  Character  set 

All  Reserved  words,  names  and  numbers  must  be  composed  of 
characters  in  the  'IPL  character  set.  The  attached  list  gives 
for  each  ASCII  character  a code  of  1 to  U classifying  the 
characters  into  the  following  categories: 

Code  1:  Nonprinting  operating  System  and  transmission  control 
characters  to  be  treated  as  punctuation,  but  will  always  be 
illegal . 

Code  2:  Puncutation,  delimitars,  etc.  which  are  not  allowed  in 
names. 

Code  3:  Characters  allowed  at  any  position  in  a name. 

Code  U;  Characters  allowed  at  any  position  in  a name  after  the 
firs’- . 

There  are  three  versions  of  this  categorization: 

1.  A one  cage  summary. 

2.  Ported  by  Octal  representation. 

3.  Ported  by  code,  then  by  Octal  representation. 
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1 


TT 


Cn  DE 

1: 

All  others 

CODE 

2: 

••p-'*,:  ; = ?| 

CODE 

3: 

abcdefghijklmnopqrstuvwxyz 

abed  efqh  i ■jklmnopqrstuvwxv? 

CODE 

4: 

012.34567B9 

requirements  language  manual 
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COPE 

HEX 

CHAf 

NAME 

1~ 

oo” 

n ul 

null  or  tine  fill  char 

1 

01 

s oh 

s'-art  of  heading 

1 

02 

s tx 

start  of  text 

1 

03 

PtX 

end  of  text  (FCM) 

1 

04 

p f 

punch  off 

1 

05 

ht 

horizontal  tab 

1 

06 

Ic 

lower  case 

1 

07 

del 

dele  te 

1 

OH 

1 

09 

1 

OA 

smni 

start  of  manual  message 

1 

OB 

vt 

vertical  tabulation  (VT) 

1 

OC 

f f 

form  feed  (FORM) 

1 

00 

c:  r 

carriage  return  (RETURN) 

1 

OE 

so 

shift  out 

1 

f)p 

s i 

shift  in 

1 

10 

d le 

data  link  escape 

1 

11 

del 

device  control  1 (X-ON) 

1 

12 

dc2 

device  control  2 (TAPE) 

1 

13 

t m 

tape  mark 

i 

14 

res 

restore 

1 

15 

n 1 

new  line 

1 

16 

b s 

back  spa  ce 

1 

17 

il 

idle 

1 

18 

can 

cancel 

1 

19 

e m 

end  of  medium 

1 

1A 

cc 

cursor  control 

1 

IB 

c u 1 

customer  use  1 

1 

1C 

i fs 

interchange  file  separator 

1 

IP 

igs 

interchange  group  separator 

1 

IE 

irs 

interchange  record  separator 

1 

IE 

i us 

interchange  unit  separator 
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HEX 

CHAP 

NAME 

T 

20  “ 

<i  s 

digit  select 

1 

21 

SOS 

start  of  significance 

1 

22 

f s 

field  separator 

1 

23 

1 

24 

byp 

bypass 

1 

25 

If 

line  feed 

1 

25 

etb 

end  of  transwission  block 

1 

27 

a sc 

esca  pe 

1 

2B 

1 

24 

1 

2A 

s m 

set  mode 

1 

23 

c u2 

customer  use  2 

1 

2C 

1 

2D 

e nq 

enquiry 

1 

2E 

a ck 

acknowledge 

1 

2P 

b el 

bell 

1 

30 

1 

31 

1 

32 

s vr 

synchronous  idle 

1 

33 

1 

34 

on 

punch  on 

1 

35 

r s 

reader  stop 

1 

36 

II  c 

upper  case 

1 

37 

“ ot 

end  of  transmission 

1 

3'^ 

1 

39 

■1 

1 

3A 

1 

33 

C’j3 

customer  use  3 

i 

3C 

d c4 

device  control  4 

1 

3D 

n ak 

negative  acknowledge 

1 

3'=’ 

1 

3P 

sub 

substit  ute 
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CODE 

HEX 

CHAP 

2“ 

40" 

sk  p 

1 

41 

1 

42 

1 

43 

1 

44 

1 

45 

1 

46 

1 

47 

1 

4H 

1 

49 

1 

4A 

g 

4B 

0 

a 

4C 

< 

3 

4D 

( 

g 

4E 

+ 

2 

4E 

I 

2 

50 

& 

1 

51 

1 

52 

1 

53 

1 

54 

1 

55 

1 

56 

1 

57 

1 

58 

1 

59 

3 

5A 

1 

3 

5B 

2 

5C 

* 

3 

5D 

) 

2 

5E 

9 

3 

5F 

”1 

name 

space 


cent  sign 
pe  r i od 

less-than  sion 
left  parenthesis 
plus  sign 
logical  OR 
aaoersan  d 


exclamation  point 
dollar  sign 
asterisk 

right  parenthesis 
semicolon 
logical  NOT 
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CODE 

-- 

HEX 

c 

MilZ 

?o“ 

- 

minus  siqn,  hyphen 

U 

61 

/ 

slash 

1 

62 

1 

63 

1 

64 

1 

66 

1 

66 

67 

1 

68 

1 

69 

1 

6A 

2 

6B 

9 

com  Da 

3 

6C 

T 

percent 

4 

60 

underscore 

4 

6E 

>" 

qreater-than  siqn 

2 

6F 

question  mark 

1 

70 

1 

71 

1 

72 

1 

73 

1 

74 

1 

75 

1 

76 

1 

77 

1 

78 

3 

79 

2 

7A 

j 

colon 

3 

7B 

t 

number  sign 

3 

7C 

d 

at  siqn 

2 

70 

f 

prime,  apostrophe 

2 

75 

equal  sign 

2 

7P 

tf 

quotation  mark 
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CODE 

HEX 

SUM 

NAME 

1 

80" 

c nd 

command  operand  indicator 

3 

81 

a 

3 

82 

b 

3 

83 

c 

3 

84 

d 

3 

85 

e 

3 

86 

f 

3 

87 

9 

3 

88 

h 

3 

89 

i 

1 

8A 

1 

88 

1 

BC 

1 

BD 

1 

HE 

1 

8F 

1 

90 

3 

91 

1 

3 

92 

k 

3 

93 

1 

3 

94 

in 

3 

95 

n 

3 

96 

o 

3 

97 

P 

3 

98 

q 

3 

99 

r 

1 

9A 

1 

9B 

1 

9C 

9D 

1 

9E 

1 

9? 
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CODE 

HEX 

CHAR  NAME 

1** 

E0~ 

1 

El 

7 

E2 

s 

3 

E3 

■p 

3 

E4 

U 

3 

E5 

V 

3 

E6 

V 

3 

E7 

X 

3 

E8 

Y 

3 

E9 

1 

1 

EA 

1 

EB 

1 

SC 

1 

ED 

1 

EE 

1 

EE 

4 

FO 

0 

4 

FI 

1 

4 

F2 

2 

4 

F3 

3 

4 

F4 

4 

4 

F5 

5 

4 

Ff 

6 

4 

F7 

7 

4 

F8 

8 

4 

F9 

9 

1 

FA 

1 

FB 

1 

FC 

1 

FD 

1 

FB 

1 

FF 
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CODE 

HEX 

SiJAF 

oo“ 

n 111 

null  or  tine  fill  char 

1 

01 

s oh 

start  of  heading 

1 

02 

s tx 

start  of  text 

1 

03 

etx 

end  of  text  (ECM) 

1 

04 

Pf 

punch  off 

1 

05 

ht 

horizontal  tab 

1 

06 

Ic 

lower  case 

1 

07 

del 

dele  te 

1 

08 

1 

09 

1 

OA 

san 

start  of  nanual  nessage 

1 

OB 

vt 

vertical  tabulation  (VT) 

1 

OC 

f f 

fors  feed  (FORM) 

1 

00 

c r 

carriage  return  ’RN) 

1 

OE 

so 

shift  out 

1 

OF 

si 

sh i f t in 

1 

10 

d le 

data  link  escape 

1 

11 

dc1 

device  control  1 (X-ON) 

1 

12 

dc2 

device  control  2 (TAPE) 

1 

13 

t !» 

tape  mark 

1 

14 

res 

restore 

1 

15 

n 1 

new  line 

1 

16 

b s 

backspace 

1 

17 

il 

idle 

1 

18 

can 

cancel 

1 

19 

e SI 

end  of  mediuis 

1 

1A 

cc 

cursor  control 

1 

IB 

c u1 

customer  use  1 

1 

1C 

i fs 

interchange  file  separator 

1 

ID 

igs 

interchange  group  separator 

1 

IE 

irs 

interchange  record  separator 

1 

IF 

1 us 

interchange  unit  separator 
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code 

HEX 

NAME 

■»” 

20~ 

d s 

diqit  select 

1 

21 

s os 

start  of  significance 

1 

22 

f s 

field  separator 

1 

23 

1 

24 

hyp 

bypass 

1 

25 

If 

line  feed 

1 

26 

9tb 

end  of  transmission  block 

1 

27 

P sc 

escape 

1 

28 

1 

29 

1 

2A 

s m 

set  node 

1 

2B 

cu2 

custoaer  use  2 

1 

2C 

1 

2D 

e nq 

enquiry 

•1 

2E 

a ck 

acknowledge 

1 

2F 

bel 

bell 

1 

30 

1 

31 

1 

32 

s yn 

synchronous  idle 

1 

33 

1 

34 

pn 

punch  on 

1 

35 

r s 

reader  stop 

1 

36 

u c 

upper  case 

1 

37 

eot 

end  of  transmission 

1 

3B 

1 

39 

1 

3 A 

1 

3B 

c u7 

customer  use  3 

1 

3C 

dc4 

device  control  4 

1 

3D 

nak 

negative  acknowledge 

1 

3E 

1 

3F 

sub 

substit  ute 
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CODE 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 


HEX 

41" 

42 

43 

44 

45 

46 

47 

48 

49 
4A 

51 

52 

53 

54 

55 

56 

57 

58 

59 
62 

63 

64 

65 

66 

67 

68 

69 
6A 

70 

71 

72 

73 


CHAP  NAMF 


t cent  sign 
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CODE 

T 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 


HEX 

7a" 

7S 

7*5 

77 

78 
RO 
8A 
RB 
8C 
RD 
RE 
3P 
90 
9A 
9B 
9C 
9D 
9E 
9F 
AO 
A1 
AA 
AB 
AC 
AD 
AE 
AF 
BO 
B1 
B2 
B3 
B4 


CHAP  153  E 


end  coMisand  operand  indicator 
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code 

HEX 

CHAR 

T“ 

ef“ 

1 

FA 

1 

FB 

1 

FC 

1 

FD 

1 

FE 

1 

FP 

2 

40 

s Xp 

space 

2 

4F 

1 

logical  OR 

2 

50 

R 

arapersa  n i 

2 

5C 

4t 

asterisk 

2 

5E 

t 

sem icol on 

2 

6B 

i 

comma 

2 

6F 

7 

question  mark 

2 

7A 

; 

colon 

2 

7D 

f 

prime,  apostrophe 

2 

7E 

■S 

equal  sign 

2 

7F 

tl 

quotation  mark 

3 

4P 

( 

left  parenthesis 

3 

5A 

1 

exclamation  point 

3 

5B 

n 

dollar  sign 

3 

5D 

) 

right  parenthesis 

3 

5F 

logical  NOT 

3 

6C 

percent 

3 

70 

3 

7B 

1 

number  sign 

3 

IZ 

at  sign 

3 

81 

a 

•> 

82 

b 

3 

83 

c 

3 

34 

d 

3 

35 

e 

i 
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t 


CODE 

HEX 

CHAR  NAME 

""3“ 

fle" 

f 

3 

87 

q 

3 

88 

h 

3 

89 

i 

3 

91 

1 

7 

92 

k 

3 

93 

1 

3 

94 

ra 

3 

95 

n 

3 

96 

0 

3 

47 

p 

3 

98 

q 

3 

99 

r 

3 

A2 

s 

3 

A3 

t 

3 

A4 

u 

3 

A5 

V 

3 

A6 

V 

3 

A7 

X 

3 

A8 

y 

3 

A9 

z 

3 

Cl 

A 

3 

C2 

i3 

3 

C3 

C 

3 

C4 

0 

3 

C5 

s 

3 

C6 

F 

3 

C7 

G 

3 

C8 

H 

3 

C9 

I 

3 

D1 

J 

3 

02 

K 
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CODF  HEX  CHAP 

*”3“  D3~  L 

3 D4  M 

3 D5  N 

3 D6  0 

3 07  P 

3 03  Q 

3 po  R 

3 E2  S 

3 E3  T 

3 £4  n 

3 £5  V 

3 £5  W 

3 £7  X 

3 £3  Y 

3 £9  Z 

4 4B 

4 4C  < 

4 4E  v 

4 60  - 

4 61/ 

4 60  _ 

4 6F  >~ 

4 FO  0 

4 FI  1 

4 F2  2 

4 F3  3 

4 F4  4 

4 F5  5 

4 F6  6 

4 VI  1 

4 F8  9 

4 F9  9 

The  one  exception  to  this  is  that  any  characters  may  be  used  in 
the  text  of  a comment  entry  statement. 

1 . 6 . P Fo^a  t Restrictions 

while  URL  is  a free  format  lanquage,  there  are  certain 
restrictions  that  have  been  incorporated  into  the  implementation 
of  UFA  to  facilitate  entry  of  Problem  Statements. 

One  restriction  is  concerned  with  length  of  the  statement. 

Though  a statement  may  extend  over  any  number  of  lines,  only  the 
first  72  columns  of  a card,  or  characters  in  a message  of  each 
line  may  he  used.  Anything  over  this  will  be  ignored. 

Therefore,  the  statement; 

RFCETVED  BY;  employee-processing; 
mav  also  be  given  as; 


NAME 


period 

less-than  sign 
plus  sign 

minus  sign,  hyphen 
slash 

underscore 
greater-than  sign 
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P ECFI VEH 
BY 

pmnl oype- pro cpss ing 


with  no  effpot  on  how  this  statement  is  interpreted  by  UPA.  The 
only  restriction  is  that  the  statement  may  only  be  split  where  a 
blank  is  allowed  and  not  in  the  middle  of  a reserved  word  or 
user  defined  name. 

A second  restriction  is  the  one  mentioned  above  for  comment 
entries.  The  type  of  Comment  Entry  such  as  DESCRIPTION  or 
PROCEDTIFE  must  appear  on  a separate  line,  followed  by  the  text 
Pnd  inq  in  a semi-colon. 

A third  restriction  is  the  use  of  ECF  as  a special  type  of 
statement  that  designates  the  end  of  a collection  of  URL 
sections  to  be  used  as  input  to  URA.  This  statement  specifies 
that  there  are  no  more  URL  statements  followinq  and  that  URA  may 
stop  processing  of  the  URL  statements.  The  EOF  statements  must 
be  used  whenever  URL  statements  are  given  as  innut  to  the 
INPUT-PSL  or  DELETF-PSL  commands  in  URA. 


'^•7  Com  parison  of  Manual  and  Computer-Aided  Documentation  in 
logical  Sys terns  Design 


1.7.1  Description  in  a Structured  Language  Compared  to  Manual 
Methods  Using  Narrative.  Forms  and  Charts 

A number  of  desirable  properties  of  documentation  were  outlined 


in  Sec*’ ion  1.1.  The  present  manual  and  computer-aided  methods 
may  be  compared,  as  follows: 

Present 

Manual  Computer-Aided 

Documentat ion  Docu  mentation 


Hard  to  Understand 
A mbiguous 
Inconsistent 
I ncom  plete 
T ncorrect 

Difficult  to  Analyze 
and  Evaluate 
Hard  to  Modify 


Understandable 
Precise 
Consistent 
Comple  te 
Correct 

Computer-Aided  Analysis 
and  Evaluation 
Computer-Aided-Updat ing 


A more  comprehensive  description  of  how  desirable 
characteristics  of  computer-aided  documentation  can  be  achieved 
is  given  in  Section  5.  Tne  contribution  of  the  structured 
description  language  is  outlined  in  1.7.2  and  the  contribution 
of  the  outputs  available  for  URA  is  outlined  in  1.7.3. 
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1.7.2  The  1 Strqctured  Description  Language 

The  «aior  characteristics  of  URL  for  describing  systeas  are; 

1)  Each  obiect  has  a unique  naae. 

2)  Each  relationship  has  a precise  foraat,  i.e.,  syntax. 

3)  Only  a specified  nuaber  of  relationships  may  exist  aaonq 
objects  of  given  types. 

4)  Any  number  of  properties  may  be  defined  for  objects  of  a 
given  type  but  each  property  must  be  uniquely  named. 

The  differences  between  URL  and  the  usual  method  of 
documentation  with  narrative  text  and  aanual  flow  charts  are 
shown  in  the  following  table; 


Narrati ve  URL 


object  Names 

unlimited 

unique 

Number  of  objects 

unlimited 

essentially  unlimited  - 
limited  only  because  names 
must  not  be  more  than  30 
characters  and  the  first 
letter  character  must  be 
a letter 

TYpe  of  objects 

not  necess- 
arily stated 

relatively  small  number 
of  explicitly  defined 
types 

Rel ationships 

unlimited  and 
not  necess- 
arily expli- 
citly defined 

relatively  small  number 
of  explicity  defined 
types 

Properties 

unlimited  and 
not  necess- 
arily expli- 
citly defined 

unlimited  but 
explicitly  defined 

1.7.3  Outputs  A vail  able  from  URA 

URA  provides  a number  of  standard  outputs  which  can  be  used  to 
satisfy  the  documentation  reguirements  for  aiding  the; 

Problem  Definer  in  His  Own  Hork 
Problem  Definer  in  communication  with  Users 
Coordination  in  Project 
Pinal  Documentation 


1.7.4  c hanges  in  Log  tea  1 De  si^gn 
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~hp  usp  of  a rronputec-aidPd  system  allows  changes  in  the  wav 
loTical  desian  is  carried  out.  Table  1.7.1  summarizes  the 
di.ferences  between  the  manual  and  computer-aided  methods  and 
the  resultini  improvements  in  the  various  logical  system  design 
activitGs:  da*:a  collection,  analysis,  design,  evaluation  and 

imp  rovement  . 
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Difference  Between  Manual  and  Conpater -A ided 

Me  thods 

Dat  a 

Col lect ion 

Forms  of  standard  UHL  format  car  be  used  to 
record  collected  data. 

Analysis 

Analyses  for  correctness,  coicpleteae.is  and 
consistency  of  data  are  done  when  innutTin" 
data  to  UFA  and  on  demand  from  L'RA. 

Design  of 
ProDosed  System 

"'hough  design  is  a creative  process,  UHA  c<jn 
mate  more  data  available  to  the  detig  a r. ' 'a 

a formatted  matter. 

^va  luat  ion 

UFA  generates  accurate,  standard  reports  to 
in  the  evaluaticn  process. 

Imp  rovement 

Modification  of  the  problem  statement  is  easi.  / 
made  through  availability  of  data-base 
modification  commands. 

Improvement  in  Computer-Aided  Methods 

Dat  a 

Col lect ion 

Outputs  from  UFA  can  provide  a checklist  for 
deciding  what  additional  information  is  neeied. 

A na Ivsi s 

Use  of  the  "UFA  data-base"  insures  that 
analysis  is  always  performed  on  an  up-to-date 
version  of  the  problem  statement.  As  new 
analysis  methods  are  developed,  they  can  be 
incorporated  into  UBA. 

Design  of 
Proposed  System 

Use  of  the  URA  reports  allows  the  designer  to 
look  at  particular  aspects  of  the  system  of 
interest.  Simple  modifications  to  the 
data-base  can  present  alternatives  in  design. 

’=’va  luat  ion 

UFA  provides  some  rudimentary  facilities  for 
computing  volume  or  work  measures  from  the  data 
in  the  problem  statement.  As  additional 
methods  are  developed,  they  can  be 
incorporated . 

Improvement 

Father  ♦•han  "starting  from  scratch"  to 
incorporate  changes  in  the  problem  stJtement, 
improvements  can  be  made  on  the  original  URA 
dat  a-base. 

Table  1.7.1 

Chanqes  in  Logical  Design  Procedure  and  Value  of  Change 
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2.  PROBLEM  S-^ATEMENT  FACILITIES  PY  SYSTEM  ASPECT 

To  accurately  describe  a system  it  is  necessary  to  describe  all 
aspects  identified  in  1 . <4 , The  followinq  sections  present  the 
BHL  ohiects  and  OFL  statements  that  pertain  to  each  aspect  of 
the  system  description: 

System  '=’low 
System  Structure 
Data  Stru ctur e 
Data  Derivation 
System  Five 
System  Dynamics 
System  Architecture 
System  Properties 
Prciect  Manaqement 

Guidelines  a r®  also  provided  to  aid  the  analyst  in  describing  a 
particular  system  in  rjPL,  including  guidelines  to  help  map  the 
obiects,  as  they  exist  in  the  real  world,  into  what  they  may  be 
called  in  DPL  terminology.  "^he  Analyser  outputs  relevant  to 
each  aspect  of  the  description  are  also  presented  to  aid  the 
analyst  in  making  the  description  consistent  and  complete. 


The  explanations  of 
precision: 


UPL  statements  ace  given  at  three  levels  of 


"must”  - denotes  that  this  is  checked  by  URA  and  not  entered 
into  the  data-base  unless  correct.  Note  the  "must” 
does  not  necessarily  imply  in  this  sense  that  the 
particular  statement  has  to  be  in  the  data-base. 

"can”  - denotes  that  a choice  is  available.  Each  choice 

selected  is  checked  by  UFA  and  not  entered  into  the 
data-base  unless  correct. 


"sh  ould" 


"implies" 

and 

"may" 


denotes  that  this  is  not  checked  by  URA  before  stored 
in  the  data-base  but  is  necessary  for  a complete 
description  of  the  target  system.  Some  of  these 
"completeness"  checks  are  made  when  producing  URA 
reports  and  warning  messages  are  produced.  Others 
can  be  made  by  the  analyst  using  URA  reports. 

•denotes  the  semantic  meaning  of  the  statement. 

This  is  not  checked  by  URA  nor  necessary  for  a 
complete  description.  Interpretation  is  to  be 
decided  by  the  Problem  Definer  and  organization. 


2. 1 System  Boundaries  and  I nput/Output  Flow 

One  UFA  data-base  describes  one  Information  Processing  System 
and  ob-)ects  associated  with  it.  The  description  of  a system  can 
beain  by  describing  its  boundaries.  (Identifying  the  boundary 
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of  a system  is  not  always  easy;  considerations  involved  in  tais 
process  are  discussed  in  4.1.)  This  section  describes  the  URI, 
facilities  in  specifying  system  boundaries  and  flow  to  and  from 
the  system. 


2.‘'.i  Fystem  Flow  Objects 

'^he  boundary  of  the  target  system  is  described  in  terms  of  t e 
objects  which  flow  across  the  boundaries. 


INPUT 


OUTPUT  - 


SFT  - 


an  object  which  contains  data  and  flows  into  the 
target  system  from  an  external  object  (i.e., 
INTFRT='ACE)  to  an~internal  object,  (i.e.,  a PROCESS). 

an  object  which  contains  data  and  flows  from  the 
target  system  to  an  external  object  from  an  internal 
object  (i.e.,  a PROCESS)  to  an  external  object  (a.e 
an  INTERFACE)  . 

an  object  which  designates  a collection  of  data 
containers  and  is  stored  and  updated  by  an  internal 
object,  (i.e.,  PROCESS). 


INTERFACE  (or  REAL-WORLD-ENTITY)  - an  external  object  which  can 
produce  an  TNPU'^,  receive  an  OUTPUT  or  be  RESPONSIBLE 
FOP  a SET. 


PROCESS 


an  internal  object  which  can  accept  an  INPUT  or 
produce  an  OUTPUT  or  UPDATE  a SET. 


2.1.2  S vst e m Flow  Relationships 

"he  verbs  in  the  above  definitions  that  are  formal  UHL 
relationships  are; 


OENEFATES/OSNERA'^ED  BY 


An  interface  must  GENERATE  an  INPUT  or  the  INPUT  must  be 
OSNERATED  BY  an  INTERFAC’='.  A PROCESS  must  GENERATE  an  OUTPUT  or 
the  CUTPir  must  be  GENERATED  BY  a PROCESS. 


'’ECEIVES/RECEIVED  BY 

An  TNT’='RFACE  must  RECEIVE  an  OUTPUT  or  the  OUTPUT  must  be 
PFCETVFD  3Y  an  IN'^ERFACE.  A PROCESS  can  RECEIVE  an  INPUT  or  the 
INPUT  can  he  RECEIVED  BY  a PROCESS. 


UPD  ATES /UPDA'’’ED  BY 
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A ^POCFSS  mas<-  oft  thp  SET  mus*:  be  UPDATED  3Y  a 

f’POC’^SS  . 


.3=''-'  PCN’SIBLE  /r.SS  PON  S T DI."-  I N T EF  FACE 

An  IVTFF'=’AOE  he  RESPONSIBLE  FCF  a SET.  A SET  mast  have  a 

PESFCNSIBLE- TNT  ERPACF. 


R.1.3  System  Fi23'  -S y nta  x and  Semantics 

The  ohiects  ind  relationships  involved  in  describinti  system  flow 
are  shown  picnorially  in  Fioare  2.1.1  and  in  tabular  form  in 
’'able  2.1.1.  The  direction  for  reading  the  table  is  from  the 
left  obiect  to  th'=‘  desired  relationship  and  then  up  to  the 
particular  obiect. 

An  IN'"FP'’ACE  can  r,Fi;EPA'’r  any  number  of  INPUTS,  RECEIVE  any 
number  of  on"'PU""S,  and  be  RESPONSIBLE  for  any  number  of  SF7S. 

An  INPUT  can  be  0-NFPATED  by  any  number  of  INTERFACES  (implies 
any  one  of  ■’•hem  must  r.'='N  EP  A"  S it)  and  be  RECEIVED  BY  more  tlian 
one  PROCESS  (implies  that  all  of  them  must  RECEIVE  it). 

A SFT  may  hav°  anv  number  of  F ESPCNSIPLE-TNTERF  ACES  (this 
implies  that  all  ar“)  and  may  be  UPDATED  by  any  number  of 
RR0CF3SES  (implies  ♦•hat  all  io)  . 


2.1.4  Ei-Stem  Flow  Common  23uivale_nts  and  Usa^S 

The  obiect-tvpes  a^d  relationships  correspond  closely  to  those 
in  ccmtnon  usao'^  when  applied  to  an  information  processing 
system.  The  main  difference  involved  is  that  in  most  manual 
documentation  methods,  the  name  INPUT  is  related  to  any  obiect 
which  is  used  by  a PROCESS  and  likewise,  an  OUTPUT  is  related  to 
anv  obiect  which  is  derived  by  a EBOCSSS.  In  general,  no  effort 
is  made  to  distinguish  between  different  levels  of  data  when 
INPUTS  and  OUTPUTS  are  thouaht  of  in  this  way. 

INPUTS  and  outputs  are  the  names  for  logical  collections  of  data 
whose  values  may  eventually  appear  on  physical  media  which 
contain  data  values  — such  as  forms,  cards,  tapes,  messages, 
reports.  Each  individual  inout  or  output  document  is  usually 
one  of  a number  of  instances.  The  INPUTS  and  OUTPUTS  being 
described  in  URL  may  have  multiple  instances.  In  UPL  the 
emphasis  is  on  the  Icuical  definition  rather  than  the  physical 
and  hence,  he  m^dia  or  the  physical  format  need  not  be 
soe  ci f i ed . 

The  use  of  PFCETVES  implies  that  some  physical  process  will  be 
roTJired  to  receive  or  accept  the  input  "document."  Similarly, 
GENERATES  implies  a process  will  be  required  in  the  implemented 
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tarqet-  system  to  nhysically  produce  the  OUTPUT. 
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ts  for  System  INPUT/OUTPUT  Flow 

1 


SYSTEM  INPUT/OUTPUT  FLOW 


IBH360/370/VS/TSO  DHL  DSEP’S  MANUAL 


68 


A can  be  interpreted  as  a master-file  or  data-base,  or  more 

broadly  to  include  very  volatile  master  files  such  as,  for 
example,  ooen-order  files.  UPDATE  implies  an  operation  in  vhish 
some  data  values  in  the  SET  are  changed.  The  RESPONSIBLE  FOR 
statement  carries  the  common  connotation  of  a data-base 
"belcnging"  to  some  unit  in  the  organization. 

A REAL-WORLD-ENTITY  (or  INTERFACE)  is  an  object  not  part  of  the 
system  being  described,  but  interacts  with  the  system  in  some 
way.  Examples  are;  employees,  departments,  companies,  etc. 


2.1.5  System  Fl ow  Outputs 

The  PICTURE  report  (with  FLOW  option  in  effect)  can  be  used  to 
present  the  system  flow  relationships  (RECEIVES,  GENERATES, 
etc.)  among  INPUTS,  OUTPUTS,  INTERFACES  and  PROCESSES  in  a 
graphical  format. 

The  PROCESS- INP  UT/0  UTPUT  report  presents  the  same  information  as 
described  above  for  PROCESS  names,  but  in  an  alternate  format. 
This  report  will  also  present  any  DESCRIPTION  statements  relate! 
to  the  PROCESS  names. 


2.1.6  System  F 1 ow  C ompleteness  Chechs 

The  completeness  checks  that  can  be  made  for  system  flow 
completeness  are: 

Every  INTERFACE  should  either  (i)  GENERATE  some  INPUT  or  (ii) 
RECEIVE  some  OUTPUT  or  (iii)  be  RESPONSIBLE  for  some  SET. 

Every  INPUT  should  be  GENERATED  by  at  least  one  INTERFACE. 

Every  OUTPUT  should  be  RECEIVED  by  at  least  one  INTERFACE. 

Every  INPUT  should  be  RECEIVED  by  at  least  one  PROCESS. 

Every  OUTPUT  should  be  GENERATED  by  at  least  one  PROCESS. 

The  last  four  checks  can  be  made  by  using  the  DATA  PROCESS 
report . 


2 . 2 System  Structure 

PeC  init  ion  of  Structure 

A number  of  the  objects  in  the  description  of  systems  are 
related  to  each  other  by  one  object  being  a "component"  of  one 
or  mere  other  objects  or  "belonging"  to  it  in  some  way. 
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Rea  sons  for  Structure 

Structural  relationships  may  be  defined  for  one  of  two  reasons. 
Structural  relationships  are  said  to  arise  from  the  "real  worli" 
if  they  are  part  of  the  description  of  the  target  system  and  its 
associated  objects,  i.e.,  if  they  really  exist.  Structural 
relationships  are  said  to  be  "definitional"  if  they  are  made  for 
convenience  in  the  process  of  describing  the  target  system  but 
do  not  exist  for  other  reasons.  Real  world  structure  must  be 
maintained  as  part  of  the  system  description  but  definitional 
relationships  may  be  discarded  when  no  longer  needed. 

The  description  of  structure  permits  "summarization"  of  the 
Problem  Statement  at  various  levels  of  the  structure  and, 
therefore,  facilitates  top-down  or  bottom-up  problem  definition 
and  approval  at  various  levels  of  completion. 


Rep cesentat ion  of  Structure 

Structural  relationships  are  usually  called  trees  or  directed 
networks  and  represented  as  shown  in  Figure  2.2.1.  The  objects 
are  represented  by  dots  called  nodes  and  the  (structure) 
relationships  by  the  lines,  called  arcs,  connecting  them.  Trees 
and  networks  are  "directed"  in  that  the  nodes  are  identified  by 
the  level.  For  example,  A is  a higher  node  than  B,  C or  H.  A 
node  may  have  immediate  successors  or  lower  nodes,  e.g.  , the 
immediate  successors  to  J are  E,  F and  G.  Similarly,  a node  may 
have  immediate  predecessors  or  higher  nodes,  e.g.,  Q has 
immediate  predecessors  N and  P. 


Types  of  Structures  |i 

_ 

A node  which  has  no  predecessors,  i.e.,  the  highest  node  is  j 

called  the  root  of  the  structure,  e.g.,  A and  M. 

- A tree  or  hia rare hical  structure  is  one  in  which  each  node 
except  the  highest  node  has  one  and  only  one  immediate 
predecessor  (Figure  2.2.1a). 

- A directed  sstwork  structure  is  one  in  which  each  node  except 
the  highest  node  may  have  more  than  one  immediate  predecessor. 

If  the  structure  contains  no  cycles,  it  is  said  to  be  acyclic 
(Figure  2.2.1b)  . 

A node  which  has  no  successors  is  called  a leaf  or  a terminal 
node  . 

In  some  cases,  a structure  may  contain  objects  of  different 
types.  A structure  containing  objects  of  only  one  type  is  a 
"homooeneou s"  structure;  one  containing  more  than  one  type  is 
called  "non-hoMoqeneous. " 
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A terainal  node  aay  be  assigned  to  the  highest  possible  level  oc 
the  lowest  possible  level,  e.g.,  node  D nay  be  regarded  as  being 
on  the  saae  level  as  J or  on  the  saae  level  as  E,  F and  G. 


A 

0 


M 

0 


• • 

BO  0 C 

• • • • 

« • 0 • 

• • • • 

DO  JO  0 

..  . H 

...  01 
... 

0 0 0 

E F G 

(a) 

Tree  Structure 


• • 

NO  OP 


0 0 0 Q 

. . 0 T 


* • • • 

0 0 0 0 
P S D V 

(b) 

Directed  Network  Structure 


Figure  2.2.1 

Tree  and  Network  Structures 


Str  ucture  in  ORL 

In  ORL,  nodes  represent  objects  and  arcs  represent  structural 
(and  other)  relationships.  Two  major  types  of  structural 
relationships  are  available.  Data  structure  relationships 
involve  objects  which  are  data  elements  or  combinations  of  data 
elements.  All  other  structure  relationships  are  called  system 
structure  statements.  System  structure  statements  are  described 
in  this  section,  data  structure  statements  in  Section  2.3. 

Table  2.2.1  shows  possible  nodes,  source  of  relationship,  type 
of  structure,  lowest  unit  and  level  of  lowest  unit  for  each  type 
of  object. 
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Table  2.2.1 

CLASSIFICATION  OF  STRUCTURE  IN  URL 


» A collection  of  trees,  i.e.,  arborescence , is  pecaitted 
* Acyclic  networks 
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2.2.1  Systen  Struct  ore  fibjects 

The  following  types  of  objects  may  belong  to  systea  structures: 

INTERFACE 

INPUT 

OUTPUT 

PRCCESS 

PROCESSOR 

SET 


2.2.2  Svstea  Structure  Relationships 


SUBPAPTS  ARE/PART  OP 

'hese  statements  may  be  used  with: 

INTERFACES 

INPUTS 

OUTPUTS 

PPCCESSES 

PROCESSOFS 

E.g.,  an  INPUT  may  have  SUBPARTS  which  are  INPUTS  or  it  may  be 
PART  OF  some  other  INPUT. 


SUBSET  OF/SUBSETS  APE 

A SET  may  be  a SUBSET  of  some  other  SET  or  it  may  have  other 
SETS  as  SUBSETS. 


UTILIEES/UTILIZFD  BY 

A PROCESS  may  UTILIZE  another  PROCESS  or  it  may  be  UTILIZED  by 
other  PROCESSES. 


2.2.?  System  Structure  Syntax  and  Semantics 

The  objects  and  relationships  involved  in  describing  systen 
structure  are  shown  pictorially  in  Figure  2.2.2  and  in  tabular 
form  in  Table  2.2.2. 

A structure  defined  by  the  SUBPARTS/PART  OF  statement  is  a 
homogeneous,  hierarchical  tree,  i.e.,  all  nodes  in  a structure 
must  be  of  the  same  type  and  any  object  can  be  PART  OF  only  one 
immediate  higher  node.  A node  can  have  any  number  of  SUDP5RTS 
of  the  same  type. 

The  relationship  in  a SUBSET  OF/SOBSETS  ARE  must  be  homogeneous. 
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i.e.,  only  SETS  may  be  SUBSETS  of  other  SETS.  The  structure  may 
be  a network,  i.e.,  a SET  can  be  a SUBSET  of  any  number  of  other 
set  s. 

The  relationship  in  UTILIZED  BY/OTILIZBS  must  be  homogeneous, 
i.e.,  only  PROCESSES  can  be  UTILIZED  by  other  PROCESSES.  The 
structure  may  be  a netowrk  since  a PROCESS  can  be  UTILIZED  BY 
any  number  of  PROCESSES. 

In  general,  "subdividing"  an  object  through  a structure 
statement  does  not  directly  imply  that  relationships,  of  other 
types,  which  held  for  the  object  also  hold  for  its  SUBPARTS. 

For  example,  suppose  the  problem  statement  has  been  defined: 

a- in put ; 
a-rwe; 
a-process ; 

are  added: 

a-input; 

ab-input, a c- input; 


INPUT 

GENERATED  BY 
RECEIVED  BY 

Then  new  statements 

INPUT 

SUBPARTS 
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Pigure  2.2.2 

sons  STRUCTURAL  RELATIONSHIPS  EXPRESSIBLE  IN  URL 
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INTEPEACS  INPUT  OUTPUT  SET  PROCESS  PROCESSOR 


INTERFACE  PART  OF 
StJBPARTS 
ARE 


INPOT  PAPT  OF 

SUBPARTS 

OUTPUT  PARTS  OF 

SOBPARTS 


SET  SUBSETS 

ARE 

SUBSETS 

OF 


PROCESS  UTILIZED 

UTILIZES 

BY 

PART  OF 
SOBPARTS 
ARE 


PROCESSOR 


PART  OF 
SOBPARTS 
ARE 


Table  2.2.2 

URL  Statements  for  System  Structure 


The  Analyzer  will  not  automatically  assume  that  ab-input  and 
ac-input  are  GENERATED-BY  a-rwe  and  RECEIVED  by  a-process.  If 
the  analyst  wishes  to  make  this  statement,  he  should  add  this 
information  explicit  ly; 

INPOT  ab-input, ac-input; 

GENERATED  BY  a-rwe; 

RECEIVED  BY  a-process; 

In  practice  if  the  problem  had  been  defined  from  the  top-down, 
the  analyst  should  also  have  subdivided  the  INTERFACE  and  the 
PROCESS  when  the  input  was  subdivided. 

2.2.4  System  Structure  Common  Equivalen  ts  and  Usage 

The  tree  structure  of  INTERFACES  corresponds  to  the  hiararchical 
structure  of  most  organizations.  The  tree  structure  of  INPUTS 
and  OUTPUTS  is  used  for  convenience  in  definition. 
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It  may  also 

be 

used  to  describe; 

a)  A form 

wit 

h many  copies,  e.g.. 

INPUT: 

FORH-A; 

SUBP; 

FORM- A-COPYl , 

FORM- A-COPY2 ; 

or 


b)  Docunent  that  is  generated  and  goes  to  different  places, 

e.g., 

OUTPUT:  PORM-A; 

SUBP:  FOFB-A-DEPT-X,  (names  chosen  according 
PORM-A-DEPT-f , to  purpose  of  carrier 
POPM-A-DEPT-Z ; , or  final  destination) 

A PROCESS  has  two  types  of  structures.  The  one  developed  by 
using  SUBPARTS/PART  OF  may  be  used  for  top-down  definition  of 
the  system.  It  may  also  be  used  to  represent  the  structure  of 
nodules  in  a program  (e.g.,  BLOCKS  and  PROCEDURES  in  a PL/1 
program).  In  both  cases,  a tree  structure  is  appropriate. 

The  structure  of  PFOCESSES  developed  using  the  UTILIZED /UTILIZES 
may  be  used  to  represent  "calls"  to  program  or  a PROCESS  which 
is  used  (i.e.,  called  from)  in  a number  of  processing  seguences. 

2.2.5  System  Structure  Reports 

The  FORMATTED  PROBLEM  STATEMENT  shows  the  immediate  structure  in 
which  an  object  is  involved,  i.e.,  all  those  objects  of  which  it 
is  PART  OF,  SUBSET  OF  or  UTILIZED  BY  and  those  that  are  its 
SUBPARTS,  SUBSETS  or  it  UTILIZES. 

The  PICTURE  report  (with  the  STRUCTURE  option  in  effect) 
presents  the  SU BPARTS/PAFT  OF  relationships  for  INPUTS,  OUTPUTS, 
INTERFACES  and  PROCESSES  in  a graphical  format  of  the  immediate 
structure  of  a particular  object. 

The  STRUCTURE  report  presents  the  same  information  but  in  a list 
format  which  displays  all  levels  in  the  system  structure.  (The 
reports  listed  above  only  presents  the  structure  levels  directly 
above  and  directly  below  the  designated  object.)  Loops  in  the 
system  structure  are  detected  by  this  report. 

The  STRUCTURE  report  presents  only  PART  OP/SUBPARTS 
relationships.  UTILIZES/UTILIZED  BY  and  SUBSET  OF/SUBSETS  OP  is 
only  shown  in  the  FORMATTED  PROBLEM  STATEMENT. 


2.2.6  System  St  ruct  ure  Completeness  Checks 

All  the  completeness  statements  in  System  Flow  apply  to  each 
SUBPART  as  it  is  defined. 
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At.  each  subdivision,  the  totality  of  statements  about  the 
SUPPARTS  must  be  consistent  with  the  statement  about  the  objects 
to  which  the  PARTS  belong. 

A structure  of  INTERFACES,  since  it  represents  the  real  world, 
cannot  be  checked  for  completeness,  i.e.,  whether  the  lowest 
level  nodes  have  been  defined,  unless  terminal  nodes  are 
designated  by  an  appropriate  ATTRIBOTE. 

A structure  involving  INPUT  S/0 UTPOTS  is  not  homogeneous  since 
the  lower  nodes  represent  3P0UP  or  ELEMENTS.  The  following 
rules  should  be  observed: 

1)  All  INPUT  structures  having  SUBPARTS  should  terminate  in 
INPUTS  which  have  a media  ATTRIBUTE  (whose  value  can  be  "TO 
BF  DETERMINED,”  TBD)  and  which  contain  data  values. 

2)  An  INPUT  should  not  have  both  a SUBPART  statement  and 
CONTAINS  statement.  Only  the  lowest  level  INPUT  should 
CONTAIN  FLEMFNTS. 

3)  All  OUTPU'^  structures  having  SUBPARTS  should  terminate  in 
OUTPUTS  which  have  a media  ATTRIBUTE  (whose  value  can  be 
"TO  BE  DETERMINED,"  TBD)  and  which  contain  data  values. 

4)  An  OUTPU*^  should  not  have  both  a SUBPART  statement  and  a 
CONTAINS  statement.  Only  the  lowest  level  OUTPUT  should 
CONTAIN  ELEMENTS. 

When  a PROCESS  structure  is  defined  using  PARTS  OF/SUBPARTS  ARE 
each  PROCESS  mav  contain  SUBPARTS  as  well  as  some  PROCEDURE 
statement.  A PROCESS  which  the  analyst  does  not  wish  to 
subdivide  further  should  be  designated  a terminal  PROCESS  by  the 
use  of  an  ATTRIBUTE  statement. 

A PROCESS  which  does  not  have  any  SUBPAPTS,  should  have  a 
PROCEDURE  statement. 


2 . 3 Data  St  r uct  ure 

As  was  described  in  Section  2.2,  various  structural 
relationships  can  he  specified  in  URL  to  relate  "components"  of 
the  system.  When  the  structual  relationships  being  specified 
are  applicable  to  data  objects,  the  structures  presented  are 
termed  "data  structures." 


2.3.1  Data  Structure  Objects 


2. 3.  1.1  Data  De f ini t ion 

The  basic  objects  for  defining  data  are  ELEMENTS  and  GROUPS. 
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ELEHEM7 

An  BlEHENT  is  the  basic  unit  of  inforaation  and,  therefore, 
cannot  be  subdivided.  An  ELEMENT  is  used  to  define  an  object 
which  may  take  on  a value.  For  exaaple,  if  "eaployee 
inforaation"  was  defined  to  be  an  ENTITY,  it  would  not,  in 
itself,  have  a value.  The  ELEMENTS  aakinq  up  "eaployee 
inforaation"  such  as  "age,"  "sex,"  "salary,"  etc.,  aight  have 
values  for  a particular  instance  of  "eaployee  inforaation." 


tJROUP 

A GROUP  is  used  to  define  a collection  of  ELEMENTS  and/or  other 
GROUPS.  This  is  done  so  that  the  inforaation  naaes  on  be 
thought  to  be  related  within  the  larger  collection  of 
inforaation  (INPUTS,  OUTPUTS  or  ENTITIES).  The  naae  of  the 
GROUP  can  be  thought  to  be  synonyaous  with  the  naaes  of  the 
GROUP'S  coaponents.  In  the  exaaple  of  "eaployee  inforaation," 
the  "naae"  of  the  eaployee  aay  be  defined  as  a GROUP  where  the 
constituents  of  the  GROUP,  "first  naae,"  "aiddle  initial," 
"surnaae"  aay  be  defined  as  ELEMENTS.  The  use  of  GROUPS  is 
primarily  a notatioral  convenience. 


2 . 3 . 1 . 2 Pef  init  ion  of  Collections  of  ^ta  Values 

The  definition  of  an  ELEMENT  or  a GROUP  is  like  a definition  of 
a word  in  a dictionary.  The  definition  specifies  how  a word  is 
to  be  used  but  does  not  give  the  instances  of  its  use  in  books, 
paragraphs,  sentences,  etc. 

In  describing  inforaation  systems,  it  is  necessary  to  have  types 
of  objects  which  can  represent  the  things  in  which,  or  on  which, 
instances  (values)  of  ELEMENTS  appear.  In  URL,  there  a /e  three 
such  types  of  objects:  INPUTS,  OUTPUTS  and  ENTITIES.  The 
difference  among  these  types  of  collections  is  related  to  their 
role  in  the  target  system. 


INPUTS 

An  INPUT  is  a collection  of  information  produced  external  to  the 
target  system,  but  used  by  the  target  system.  For  exaaple,  in 
an  inventory  system,  a customer  order  aay  be  considered  an  INPUT 
to  the  systea. 
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OUTPUTS 

An  OUTPUT  is  a collection  of  infocaation  produced  by  the  target 
system,  but  which  is  used  erternal  to  the  system.  For  example, 
the  paychecks  produced  by  a payroll  processing  system  could  be 
thought  of  as  OUTPUTS  as  they  are  eventually  used  by  employees 
outside  of  the  system.  Once  the  collection  has  left  the  system, 
no  further  reference  nay  be  made  to  it. 


ENTITIES 

An  ENTITY  is  a collection  of  information  which  is  maintained 
internal  to  the  system.  ENTITIES  are  initially  "produced"  and 
then  "maintained"  using  information  from  INPUTS  and  then  OUTPUTS 
are  produced  using  information  from  ENTITIES  (and  other 
SDurces).  The  "employee  information"  mentioned  above  would  be 
defined  as  an  ENTITY. 


2. 3. 1.3  Relationshi ps  Among  Collections  of  Information 

Collections  of  information  maintained  internal  to  the  system 
(ENTITIES)  are  often  "related"  to  each  other  in  that  there  is 
information  which  is  not  inherent  to  either,  but  associated  with 
both.  In  the  example  of  a warehouse  stock  control  system, 
information  about  inventory  items  may  be  related  to  information 
about  their  suppliers,  etc.  RELATIONS  are  used  to  describe 
these  logical  connections  among  ENTITIES. 


2.3.2  Data  S^ucture  Relationships 

The  relationships  that  can  be  specified  for  data  structure  are 
shown  in  tabluar  forms  in  Table  2.3.1  and  Table  2.3.2.  This 
information  is  also  presented  in  Figure  2.3.1  in  a graphical 
format. 
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CONSISTS  OF/CONTATNED  IK 

A SET  may  CONSI ST  of  ENTITIES,  or  INPUTS,  or  OUTPUTS.  Likewise, 
an  INPUT  or  an  OUTPUT  or  an  ENTITY  may  he  CONTAINED  in  a SET. 


DELATED  TO  VIA/BETWFFN 

An  ENTITY  may  he  FELATED  to  another  ENTITY  VIA  a given  RELATION. 
A RELATION  may  be  ilefined  to  exist  BETWEEN  two  ENTITIES. 

SUB  SETT INC- CRITERIA /SUB SETTING-CRITERION 

A GROUP  or  ELEMENT  may  be  S Ufl S ETTING-CR ITER  ION  for  a SET  and  a 
ET  may  have  GROUPS  ard/or  ELEMENTS  which  are 
UBSFTTING-CRTT EFIA  . 


TDENTTFIED  BY/I DENT  I FIES 

An  ENTITY  may  be  IPENTIRIED  BY  a GROUP  and/or  ELEMENT  and  a 
GROUP  or  ELEMENT  IDENTIFIES  an  ENTITY. 


ASSOCIATED- DATA/ASSOCIA'^ED  WITH 

A PEIATION  may  have  GROUPS  and/or  ELEMENTS  as  ASSOCIATED- DATA 
Also,  a GROUP  or  ELEMENT  may  be  ASSOCIATED  WITH  "iiLATION. 


VALUE  IS 

An  ELEMENT  may  have  a particular  VALUE  or  range  of  V ALU  ES 
associated  with  it. 


2.3.3  Data  Structure  Syntax  and  Semantics 

A S YSTE H-PA P AMETEP  or  numerical  value  may  be  specified  in  the 
CONSISTS  statement  for  SETS,  INPUTS,  OUTPUTS,  ENTITIES  and 
GROUPS  to  denote  the  number  of  instances  of  the  components  for  a 
given  instance  of  the  containing  object. 

An  ENTITY,  INPUT  or  OUTPUT  may  CONSIST  of  any  number  of  GROUPS 
and/or  ELEMENTS. 

A SET  may  CONSIST  of  any  number  of  INPUTS,  OUTPUTS,  or  ENTITIES, 
but  not  a combination  of  these  object  types.  Also,  a SET  may 
have  any  number  of  GROUPS  and/or  ELEMENTS  as 
SUB  SETTING-CRITERIA . 
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An  ENTITY  can  be  IDENTIFIED  by  any  nuaber  of  GROUPS  and/or 
ELEMENTS,  and  be  RELATED  to  any  nuabec  of  ENTITIES.  However, 
for  each  unique  pair  of  ENTITIES,  a unique  RELATION  aust  be 
defined.  E.g.,  if  a RELATION  between  El  and  E2  is  defined  as 
Rl,  a RELATION  between  El  and  E3  cannot  also  be  called  HI. 

A RELATION  Bay  only  be  defined  to  be  BETHEEN  a single  pair  of 
ENTITIES.  A different  RELATION  aust  be  defined  for  each  ENTITY 
oair.  A RELATION  may  have  any  number  of  GROUPS  and/or  ELEMENTS 
as  ASSOCIATED-DATA. 

A GROUP  aay  be  CONTAINED  in  any  number  of  GROUPS,  ENTITIES, 
INPUTS  and/or  OUTPUTS.  A GROUP  may  also  IDENTIFY  any  number  of 
ENTITIES,  be  SUBSETTING-CRITERION  for  any  number  of  SETS  and  be 


ASSOCIATED  HITU  any  number 

of  RELATIONS.  In  addition 

,,  a GROUP 

may  CONSIST  of  any  number 

of  GROUPS  and/or 

ELEMENTS. 

INPUTS  OUTPUTS 

SET  ENTITY 

GROUPS 

ELEMENTS 

INPUTS 

CONTAINED 

CONSISTS 

CONSISTS 

IN 

OF 

OF 

OUTPUTS 

CONTAINED 

CONSISTS 

CONSISTS 

IN 

OF 

OF 

SET  CONSISTS  CONSISTS 

CONSISTS 

OF  OF 

OF 

ENTITIES 

CONTAINED 

CONSISTS 

CONSISTS 

IN 

OF 

OF 

GROUPS  CONTAIN-  CONTAIN- 

CONTAIN- 

CONSISTS 

CONSISTS 

ED  IN  EE  IN 

ED  IN 

OF 

OF 

CONTAINED 

IN 

ELEMENTS 

CONTAIN-  CONTAIN- 

CONTAIN- 

CONTAIN- 

ED  IN  ED  IN 

ED  IN 

ED  IN 

Table  2.  3. 1 

URL  Statements  for  Data  STRUCTURE  Relationships 
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SET 

ENTITY 

RELATION 

GROUPS 

ELEMENTS 

SUBSETTING- 

SUBSET- 

CRITERIA 

TING 

CRITERI  A 

ENTITIES 

RELATED  TO 

R/VIA 

IDENTIFIED 

IDENTI- 

BY 

FIED  BY 

RELATION 

BETWEEN 

ASSOCIATED- 

ASSOC- 

DATA 

I A TED 

DATA 

GROUPS  SUBSET'-ING- 

IDENTIFIES 

ASSOCIATED 

CRITERION 

WITH 

ELEMENT  SUBSETTING- 

IDENTIFIES 

ASSOCIATED 

VALUES 

CRITERION 

WITH 

Table  2.3.2 

URL  Definitional  Statements  Relating 
SETS,  ENTITIES,  PBLATIONS,  GROUPS  and  ELEMENTS 


An  ELEMENT  may  be  CONTAINED  in  any  number  of  GROUPS,  ENTITIES, 
INPUTS,  and/or  OUTPUTS.  An  ELEMENT  may  also  be  used  to  IDENTIFY 
any  number  of  ENTITIES,  be  SUBSETTING-CRITERION  for  any  number 
of  SETS,  and  be  ASSOCIATED  WITH  any  number  of  RELATIONS.  In 
addition,  an  ELEHEN’’’  may  take  on  a particular  numerical  VALUE  or 
a range  of  VALUES. 


2 . 3 . « Data  Structur e Common  Eqnivalents  and  Usage 

The  names  URL  uses  to  define  data  structures  are  very  close  to 
most  terminology  in  this  field.  For  example,  ELEMENTS  are  often 
referred  to  as  ''items, '•  "data  items,"  or  "fields"  in  other  data 
structure  terminologies.  GROUPS  are  sometimes  referred  to  as 
"segments"  or  "data  aggregates."  ENTITIES  are  sometimes  called 
"records"  and  SETS  sometimes  "files"  or  "data-bases." 

If  a SET  is  intended  to  represent  a "file"  where  ENTITIES  are 
"records,"  the  following  options  are  available  in  describing  the 
file  structure. 


If  the  SET  CON 

- ENTITY 

occur 

RELATION 

to  re 

- ENTITY 

o ccur 

RELATION 

to  re 

‘ If  more  than  one 
a given  SET,  a SET 
be  defined  for  each 


SISTS  Of 

only  one 

type 

of 

ENTITY,  th 

en  ; 

rences  w 

ithin  the 

SET 

may 

be  ordered 

and  so  a 

pre  sent 

this  ordering 

may 

be  defined 

. » 

rences  w 

ithin  the 

SET 

may 

not  be  ord 

ered.  A 

present 

this  need 

no  t 

be 

defined . 

RELATION  is  to  be  defined  for  ENTITIES  within 
(which  is  a SUBSET  of  the  given  SET)  should 
RELATION. 
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- ENTITY  occurrences  may  be  BELATED  to  each  other  based  on 
sose  criteria.  A RELATION  should  be  defined  to  describe 
this  relationship. 

b)  If  the  CONSISTS  of  Bore  than  one  type  of  ENTITY: 

- ENTITY  occurrences  say  be  ordered.  A RELATION  should  be 
defined  for  each  ordering.  * 

- ENTITY  occurrences  may  not  be  ordered. 

- ENTITY  occurrences  nay  be  RELATED  to  other  ENTITY  types 
(for  each  other).  A RELATION  should  be  defined  to  describe 
each  of  these  relationships. 

The  IDENTIFIES  statenent  for  GROUPS  or  ELEMENTS  may  be  used  to 
define  keys.  It  is  meant  that  the  designated  GROUP  or  ELEMENT 
may  be  used  when  searching  for  a particular  ENTITY  (record) 
occurrence. 


ROW  TO  USE  THE  RELATION  SECTION 
TO  EXPRESS  LOGICAL  CONNECTION  IN  PROBLEM  STATEMENT 


Ste£  J 

a)  Determine  symbolic  (URL)  name  for  the  RELATION.  It  is 
recomiended  that  the  name  denotes  the  type  of  connection 
that  it  will  supply. 

b)  Determine  which  ENTITIES  the  RELATION  connects  and  the 
direction  of  the  connection.  Use  the  URL  BETWEEN  and 
CONNECTIVITY  statements  to  state  this  information. 

Example : 

Suppose  the  analyst  has  the  following  (logical)  view  of  his 

dat  a : 
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♦- 

I 

I 

I 

I 

I 

♦- 


DEPARTMENT 


• ♦ 
I 
I 
I 
I 
I 


I T 

I HOURLY  I 

I EMPLOYEES  I 

T I 


+ — ♦ 

I I 

I SALARIED  I 
I EMPLOYEES  I 
I I 


The  URL  stateaents  that  define  the  two  RELATIONS  are: 

R ELATION  dept -to- hourly-employees ; 

BETWEEN  dept  AND  hourly-e aployees ; 

CCNNECTIVITT  IS  1 TO  aax-dept-hourly-eaployBent; 

RELATION  dept-to- salaried-eaployees; 

BETWEEN  dept  AND  salar ied-eaployees; 

CCNNECTTVITY  IS  1 TO  max-d^pt-salaried-eaployfflent ; 


Ste£  2 

a)  Deteraine  if  ary  data  has  been  defined  to  be  CONTAINED  in 
both  ENTITIES.  Analyze  this  data  and  determine  ENTITIES  or 
ASSOCIATED  DATA  statements. 

b)  Oetecaine  if  any  additional  data  is  needed  to  describe  the 
PELATIOM  and,  if  so,  this  data  should  be  defined  as 
ASSOCIATED  DATA. 
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Example : 

A more  refined  and  detailed  logical  view  of  the  data  given  above 
might  be; 


♦ - 

I 

1 

I 

I 

I 

♦ - 


DEPARTMENT 


I 

I 

I 

I 

I 


I last  date  I 
lenployee  hiredi 
lor  terminated  I 


4. 4 

I last  date  I 
lemployee  hiredi 
lor  terminated  I 

4............ — .4 


♦ 


♦ 


I I 

I HOURLY  I 
I EMPLOYEES  I 
I T 

4-- - 4 


4-.- 4 

I I 

1 SALARIED  I 
I EMPLOYEES  I 
I I 

4---«--»----4 


a)  Determine  the  RELATION'S  CARDINALITY 

h)  Determine  the  PROCESSES  that  utilize  the  RELATION  and  those 
PROCESSES  that  add,  delete  or  modify  the  connection 
occurrences  of  the  RELATION. 


Results; 

The  analyst  has  information  that  is  required  for  physical 
design.  There  is  a connection  between  the  programming 
requirement  and  the  data-base.  The  data-base  nay  have  to  be 
revised  to  be  receptive  to  the  processing  restrictions. 

For  an  example,  see  RELATION  Definition  Form. 


2.3.5  Data  Structure  Outputs 
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?he  CONSISTS  COMPARISON  REPORT  presents  the  lowest  level  data 
objects  (usually  ELEMENTS)  in  the  data  structure  of  the  data 
objects  used  as  input  to  the  report.  This  infornation  is 
presented  in  matrix  form  with  several  redundancy  and 
completeness  check  diaqnostics  in  a summary. 

""he  CONSISTS  MATRIX  REPORT  presents  data  structure  at  5 qiven 
level  relative  to  the  data  objects  used  as  input  to  the  report, 
for  example,  if  an  ENTITY  name  is  used  as  input  to  the  report 
and  the  CONSIS'^S  parameter  is  specified,  all  GROUPS  and/or 
ELEMENTS  the  ENTITY  CONSISTS  of  will  be  presented.  If  the 
ENTITY  name  and  the  CONTAINED  parameter  is  specified,  all  those 
SETS  the  ENTITY  is  CONTAINED  will  be  presented.  All  information 
in  the  report  is  presented  in  a matrix  format. 

The  CONTENTS  REPORT  presents  the  data  structure  at  ail  levels 
for  a qiven  data  object  as  input  to  the  report.  The  CONTENTS 
REPORT  presents  the  data  structure  going  down  to  the  lowest 
specified  in  the  problem  statement. 

The  IDENTIETEP  INFORMATION  REPORT  presents  those  ELEMENTS  and/or 
GROUPS  defined  as  IDENTIFIERS  for  a particular  ENTITY  or 
presents  the  ENTITITES  IDENTIFIED  by  a particular  GROUP  or 
ELEMENT.  This  information  is  presented  in  a matrix  format. 

The  four  reports  are  summarized  in  Table  2.3.3. 
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CON  SISTS 
COMPARISON 

CONTENTS 

CONSI 

CONSIST 

STS  MATRIX 
CONTAINED 

EPS 

SET 

X 

X 

NO 

X 

ENTITY 

X 

X 

X 

X 

INPUT 

X 

X 

X 

X 

OUTPUT 

X 

X 

X 

X 

GROUP 

X 

X 

X 

X 

ELEMENT 

X 

X 

ROM  ID 

HIGHEST 

COL 

ROM 

OBJECT 

LEVEL 

ID 

ID 

ID 

lOMEST 

NODE 

0 

NEST  HIGHER  NODE 

HIGHES"'  1 
NODE  1 

» 

1 

1 

1 

• • • 

• • • 

0 . 

0 

LOWER  1 
. NODE  1 

• 1 

1 

1 

1 

1 

I 

1 

1 

• • 

0 

• 1 

• 1 

1 

1 

• • 

C 0 

• • • ■ - ^ 

0 

0 

TABLE  2.3.3 
Data  Report  Sunnnary 

2.3.6  Data  Structure  Coapleteness  Checks 

Ml  SETS  shoult  "eventually  " consist  of  INPUTS,  OUTPUTS  or 
ENTITIES. 

All  INPUTS  at  the  lowest  level  should  consist  of  GROUPS  and 
ELEMENTS.  Any  GROUPS  should  be  reducible  to  ELEMENTS. 

ALl  OUTPUTS  at  the  lowest  level  should  consist  of  GROUPS  and 
ELEMENTS.  Any  GROUPS  should  be  reducible  to  ELEMENTS. 


2 . 4 Data  Deriva  tion 

An  infomation  processing  systea  exists  to  process  data,  i.e., 
to  produce  values  of  data  elements,  or  groups  of  data  elements, 
from  values  of  other  data  elements  or  groups.  This 
transformation  is  known  by  different  names  such  as  process, 
procedure,  function,  operation,  activity,  etc.  In  URL  the  term 
PROCESS  is  used . 

"he  term  "data  derivation"  includes  the  actions  of  USING, 
UPDATING  and  DERIVING  data  ob-Jects.  The  data  objects  that  are 
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involved  can  be  INPUTS,  OUTPUTS,  SETS,  ENTITIES,  GROUPS  and 
ELEMENTS. 


2.4.1  Data  Deri  vat  ion  Ob  leg  ts 

The  objects  involved  in  data  derivation  are: 

PROCESS 

SET 

INPUT 

OUTPUT 

ENTITY 

GROUP 

ELEMENT 

RELATION 

CLASSIFICATION 

SECURITY-  ACCESS-RIGHTS 


2.4.2  Data  Derivation  Relationships 

USES/OSED  - A PROCESS  lay  U^  a SET,  INPUT,  ENTITY, 

GROUP  or  ELEMENT.  Likewise,  a SET, 

INPUT,  ENTITY,  GROUP  or  ELEMENT  aa/  be 
USED  by  a PROCESS. 

UPDATES/DPDATED  - A PROCESS  may  UPDATE  a SET,  ENTITY, 

GROUP  or  ELENENtT  and  a SET,  ENTITY, 

GROUP  or  ELEMENT  may  be  UPDATED  by  a 
PROCESS. 

OERIVES/DERIVED  - A PROCESS  may  DERIVE  a SET,  OUTPUT, 

ENTITY,  GROUP  or  ELEfjiNT , an  d a SET, 
OUTPUT,  ENTITY,  GROUP  oc  ELEMENT  may  be 
DCTIVED  by  a PROCESS. 

MAINTAIMS/M AINT AINED  - A PROCESS  may  MAINTAIN  a RELATION,  and 

a RELATION  may  be  MAINTAINED  by  a 
PROCESS. 

PROCEDURE  - A PROCESS  may  have  a PROCEDURE 

associated  with  it.  The  PROCEDURE  is  a 
comment  entry  and  may  consist  of  any 
text . 

DERIVATION  - A RELATION  or  SET  may  have  a DERIVATION 

associated  with  it  in  the  form  of  a 
comment  entry. 

CLASSIFICATION  - A data  object  may  have  a 

CLASSIFICATION. 

SECURITY-ACCESS-PIGHTS  - A PROCESS  or  PROCESSOR  may  have 
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SECURITY- ACCESS- RIGHTS. 


2.4.3  Data  Deri vati on  Synta  x and  Seaantics 

The  objects  and  relationships  inyolved  in  describing  "data 
derivation"  are  shown  pictorially  in  Figure  2.4.1  and  in  tabular 
fora  in  Table  2.4.1.  Table  2.4.2  shows  how  the  different  types 
of  objects  can  appear  in  the  data  derivation  stateaents.  Table 
2.4.3  contrasts  the  syntax  and  semantics  of  the  Systea  Flow 
Stateaents  (RECEIVES  and  GENERATES)  with  that  of  the  data 
derivation  statements. 

Whenever  INPUT,  OUTPUT,  ENTITY  or  SET  are  used  in  a data 
derivation  statement,  these  objects  are  interpreted  to  mean  the 
data  values  contained  in  them. 

A PROCESS  aay  USE  any  number  cf  INPUTS,  SETS,  ENTITIES,  GROUPS 
and  ELEMENTS.  An  optional  UPDATE  or  DERIVE  clause  can  be  used 
in  conjunction  with  the  USE  statement  in  the  following  manner: 

OSES  El  TO  DERIVE  E2; 

Where  E2  is  any  number  of  data  objects  that  can  be  DERIVED  by  a 
PROCESS. 

A PROCESS  can  UPDATE  any  number  of  SETS,  ENTITIES,  GROUPS  and 
ELEMENTS.  An  optional  USING  clause  can  be  used  in  conjunction 
with  the  update  statement  in  the  following  manner: 

UPDATES  El  USING  E2; 

Where  E2  is  any  number  of  data  objects  that  can  be  USED  by  a 
PROCESS. 

A PROCESS  can  DERIVE  any  number  of  OUTPUTS,  SETS,  ENTITIES, 
GROUPS  and  ELEMENTS.  An  optional  USING  clause  can  be  used  in 
conjunction  with  the  DERIVE  statement  in  the  following  manner: 

DERIVES  El  USING  E2; 

Where  E2  is  any  number  of  data  objects  that  may  be  USED  by  a 
PROCESS . 

An  INPUT,  SET,  ENTITY,  GROUP  or  ELEMENT  can  be  USED  by  any 
number  of  PROCESSES.  An  optional  DERIVE  or  UPDATE  clause  may  be 
used  in  conjunction  with  the  USED  statement  in  the  following 
manner: 

USED  BY  Pi  TO  DERIVE  E2; 

Where  E2  is  any  number  of  data  objects  that  can  be  DERIVED  by  a 
PROCESS . 
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Ob-ject 
Naiie  in 
Statement 
Sect- ion 


Type 

INPUT  OUTPUT 

SET 

ENTITY 

INPUT 

TO 

DERIVE^ 

TO  DERIVE/UPDATE’ 

TO  DERIVE/UPDATE’ 

OUTPUT 

USING* 

USING* 

USING* 

SET 

USING* 

TO 

DERIVE’ 

TO  DERIVE/UPDATE’ 

TO  DERIVE/UPDATE’ 

USING* 

USING* 

ENTITY 

USING* 

TO 

DERIVE’ 

USING* 

USING* 

TO  DERIVE/UPDATE’ 

TO  DERIVE/UPDATE’ 

GROUP 

USING* 

TO 

DERIVE’ 

USING* 

USING* 

TO  DERIVE/UPDATE’ 

TO  DERIVE/UPDATE’ 

ELEMENT 

USING* 

TO 

DERIVE 

USING* 

USING* 

TO  DERIVE/UPDATE’ 

TO  DERIVE/UPDATE’ 

USING' 

DERIVt, 

~ERIVES 

DERIVES 

TO  DBRiy. 

>ES 

OSES 

PDATES 

UPDATES 

USING' 

USING' 

TO  DERI?E/UPDATE*  TO  DERIVB/OPDATE* 


RELATION  GROOP  ELEMENT 


INPUT  TO  DERIVE/DPDATE^  TO  DERIVE/OPDATE 

OOTPHT  USINGS  USING* 


SET 

ENTITY 

TO  DERIVE/UPDATE’ 
USING* 

USING* 

TO  DERIVE/UPDATE’ 

TO  DERIVE/UPDATE’ 
USING* 

USING* 

TO  DERIVE/UPDATE’ 

GROUP 

USING* 

USING* 

TO  DERIVE/UPDATE’ 

TO  DERIVE/UPDATE’ 

ELEMENT 

USING* 

USING* 

TO  DERIVE/UPDATE’ 

TO  DERIVE/UPDATE’ 

PROCESS 


MAINTAINS 


DERIVES 

USES 

UPDATES 

USINGS 

TO  DERIVE/UPDATE* 


DERIVES 

OSES 

UPDATES 

USING' 

TO  DBRIVE/OPDATE* 


(see  following  page  for  footnotes) 

Table  2.4.1  URL  Statements  Belated  to  Derivation  Definition 
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PROCESS 

INPUT 

USED  BY 

OUTPUT 

OERIV  ED 

BY 

SET 

USED  BY 
UPDATED 

BY 

DERIVED 

BY 

ENTITY 

DERIVED 

BY 

UPDATED 
USED  BY 

BY 

RELATION 

MAINTAINED  BY 

GROUP 

DERIVED 

BY 

UPDATED 
USED  BY 

BY 

ELEMENT 

DERIVED 

BY 

UPDATED 
USED  BY 

BY 

PROCESS 

UTILI2ES 

UTILIZED 

BY 

Table  2.4.1 

URL  Statenents  Related  to  Derivation  Definition 

(Continued) 


Footnotes: 


Used 

in 

conlunction 

with 

U sed 

in 

conjunction 

with 

Used 

in 

con  ju  ncti  on 

with 

Used 

in 

conjunction 

with 

Used 

in 

conjunction 

with 

the  USED  BY  stateuent. 
the  DERIVED  BY  Statement. 

DERIVED  BY  and  UPDATED  BY  statement. 
DERIVES  and  UPDATES  statement. 

USES  statement. 


i 


I 
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ELEMENT 

GROUP 

INPUT  OUTPUT 

ENTJTl 

SET 

USES 

X 

X 

X 

X 

X 

USES  TO  DERIVE 

X 

X 

X 

X 

X 

USES  TO  UPDATE 

X 

X 

X 

X 

X 

DBR IVES 

OER  IVES/USING 

X 

X 

X 

X 

X 

UPDATES 

UPDATES/USING 

X 

X 

X 

X 

X 

DERIVES  or  UPDATES 

ELEMENT 

GROUP 

INPUT  0 UTPUT 

ENTITY 

SET 

USES 

US^'S  TO  DERIVE 

X 

X 

X 

X 

X 

USES  TO  UPDATE 

X 

X 

X 

X 

DERIVES 

X 

X 

X 

X 

X 

DER  IVES/USING 

X 

X 

X 

X 

X 

UPDATES 

X 

X 

X 

X 

UPDATES/USING 

X 

X 

X 

X 

Table  2.4.2 

Data  Derivation  Relationships  for 
USES,  UPDATES  and  DERIVES  Statements 
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ELEMENT 

GROUP 

OPUT 

RECEIVES 

Not  Alloved 

Not  Allowed 

Every  INPUT 
should  be 
RECEIVED  by 
at  least  one 
PROCESS 

GEN  EFATES 

Not  Allowed 

Not  Allowed 

Not  Allowed 

USES 

Every  ELEMENT 
should  be  used 
by  at  least 
one  PROCESS 

At  least  one 
ELEMENT  in 
the  GROUP  is 
used  by  the 
PROCESS 

At  least  one 
ELEMENT  in  the 
INPUT  is  used 
by  the  PHXESS 

DER IVES 

Value  of  an 
ELEMENT  is 
derived  by 
the  PROCESS 

Value  of  at 
least  one 

ELEMENT  in  the 
GROUP  is  de- 
rived by  the 
PROCESS 

Not  Allowed 

UPDATES 

1)  Value  of  an 
ELEMENT  is 
updated  by 

the  PROCESS 

2)  ELEMENT 
should  be 
CONTAINED 
in  at  least 
one  ENTITY 

1)  Value  of  at 
least  one 

ELEMEMT  in 
the  GROUP  is 
updated  by 
PROCESS 

2)  GROUP  should 
he  CONTAINED 

in  at  least 
one  ENTITY 

Not  Allowed 

Table  2.4.3 

Data  Derivation  (PROCESS)  Semantics 
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OUTPUT  ENTITY  SEJ 


RECEIVES 

Not  Allowed 

Not  Allowed 

Not  Allowed 

j 

GEN  ERATES 

Fvery  OUTPUT 
should  be 
GENERATED  by 
at  least  one 
PROCESS 

Not  Allowed 

Not  Allowed 

: 

USES 

Not  Allowed 

At  least  one 
ELEMENT  in 
the  ENTITY 
is  used  by 
t'he  PROCESS 

At  least  one 
ELEMENT  in  the 
SET  is  used  by 
PROCESS 

DER  IVES 

Value  of  at 
least  one 
ELEMENT  in 
OUTPUT  is  de- 
rived by  the 
PROCESS 

At  least  one 
ELEMENT  in 
the  ENTITY 
is  derived 

At  least  one 
ELEMENT  in  the 
SET  is  derived 

UPD  ATES 

Not  Allowed 

Value  of  at 
least  one 
ELEMENT  in 
the  ENTITY 
is  updated 
by  the 

PROCESS 

Value  of  at  least 
one  ELEMENT  in  the 

SET  is  updated  by 
the  PROCESS 

Table  2.4.3 
(Continued) 
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A .SFT,  ENTITY,  GROnP  or  ELEMENT  Bay  be  UPDATED  by  any  a ub  ber  of 
PTOCESSE*?-  An  optional  USING  clause  «ay  be  used  in  conjunction 
with  the  UPDATED  statement  in  the  following  Banner: 

UPDATED  BY  Pi  USING  F2; 

Where  E2  is  any  number  of  data  objects  that  may  be  USED  by  a 
PROCESS , 

An  OUTPUT,  SE^,  ENTITY,  GROUP  or  ELEMEN'^  may  he  DEPI/ED  by  any 
number  of  PROCESSES.  An  optional  USING  clause  may  be  used  in 
conjunction  with  the  DERIVED  statement  in  tne  following  manner: 

DERIVED  BY  PI  USING  E2: 

Where  E2  is  anv  number  of  data  objects  that  may  be  USED  by  a 
PROCESS . 

A RELATION  may  be  MAINTAINED  by  any  number  of  PROCESSES,  and  a 
PROCESS  may  MAINTAIN  any  number  of  RELATIONS. 

A PROCESS  may  have  any  number  of  EROCEDURE  comment  entries 
soecified,  but  all  the  comment  entries  will  he  combined  into  one 
PROCEDURE  comment  entry  when  presented  in  any  UR  A report. 

A SET  or  RELATION  may  have  any  number  of  DERIVATION  comment 
entries  specified,  but  all  these  comment  entries  will  be 
combined  into  one  DERIVATION  comment  entry  when  presented  in  any 
USA  report. 

When  a collection  of  data  (e.g.,  an  ENTITY  or  GROUP)  is  USED, 
this  implies  that  at  least  one  ELEMENT  within  the  collection 
(assuming  the  collection  is,  or  will  be,  broken  down  to  one 
ELEMENT  level)  is  USED. 

When  a collection  of  data  is  UPDATED,  this  implies  that  at  least 
one  ELEMENT  within  the  collection  is  UPDATED. 

When  a collection  of  data  is  DERIVED,  this  implies  that  at  least 
one  ELEMENT  within  the  collection  is  DERIVED. 

Whenever  PPOCESSE*'  or  PROCESSORS  access  data,  whether  deriving, 
UDdating  or  using  it,  the  CLASSIFICATION  of  the  data  and  the 
SHCUFITY-ACCESS-BIGHTS  of  PROCESS  or  PROCESSOR  should  Batch.  In 
order  to  match,  the  PROCESS  or  PROCESSOR  should  have 
SSCnpITY-ACCESS-PTGHTS  at  a level  greater  than  or  equal  to  the 
CLASSIFICATION  of  the  data  object. 


2.4.4  Data  Deri vatj on  CowBon  Egui valents  and  Usage 

In  most  manual  documentation  methods,  the  information  related  to 
"data  derivation"  is  usually  implicitly  included  in  flow  charts. 
Flow  charts  usually  contain  more  than  just  the  "data 
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derivation,"  and,  consequently,  data  derivation  lay  not  be 
clearly  presented. 

A PROCESS  that  is  UTILIZED  represents  sone  function  within  the 
system  that  is  incorporated  by  two  or  more  higher  level 
PROCESSES.  For  example,  a validation  routine  might  be  a PROCESS 
UTILIZED  by  several  other  PROCESSES  to  perform  their  defined 
functions. 

The  PROCEDURE  comment  entry  within  the  PROCESS  description  may 
be  used  to  describe  the  algorithms  required  to  define  the 
PROCESS.  Since  the  PROCEDURE  is  text,  decision  tables  may  be 
included. 

The  DERIVATION  comment  entry  within  the  SET  or  RELATION 
d‘=‘scriptions  may  be  used  to  define  the  rules  to  derive  an 
occurrence  of  a RELATION  between  two  ENTITIES,  or  occurrences  of 
a member  within  a SET. 


2.4.5  Data  Derivation  Outputs 

The  PICTURE  report  (with  the  DATA  option  in  effect)  can  be  used 
to  present  data  derivation  relationships  (USES,  UPDATES,  and 
DERIVES)  among  SETS,  INPUTS,  OUTPUTS,  ENTITIES,  GROUPS,  ELEMENTS 
and  PROCESSES  in  a graphical  format. 

The  EXTENDED  PICTURE  report  (with  the  DATA-FLOW  option  in 
effect)  can  be  used  to  present  the  all  data  derivation 
relationships  (OSES,  UPDATED,  DERIVED,  GENERATED,  and  RECEIVED) 
among  SETS,  INPUTS,  OUTPUTS,  ENTITIES,  GROUPS,  ELEMENTS, 
PROCESSES,  and  INTFPFACES  in  a graphical  tree-structured  format 
looking  FORWARD  or  BACKWARD  in  the  tree. 

The  PPOCESS-INPUT/0 UTPUT  report  presents  most  of  the  information 
as  described  above  for  PROCESS  names  only,  but  in  an  alternate 
format.  This  report  will  also  present  any  DESCRIPTION  and 
PPOCFDURE  comment  entries  related  to  the  PROCESS  names. 

The  DATA  PROCESS  report  presents  the  interaction  of  data  ob-jects 
wi'-h  PROCESSES  in  a matrix  format.  This  has  the  advantage  of 
oresert ing  the  dependencies  ot  data  by  PROCESSES  for  the  entire 
system.  A second  matrix  is  also  produced  to  present  the  degree 
in  which  PROCESSES  interact  with  each  other;  i.e.,  to  produce 
data  that  other  PROCESSES  use  or  to  require  data  that  other 
PROCESSES  produce. 


2.4.6  Data  Derivation  Completeness  Checks 

1)  Every  PROCESS  should  acquire  some  data  either  by  USING  or 
UPDATING. 

2)  Every  PROCESS  should  produce  data  by  DERIVING  or  by 
UPDATING. 
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3)  Every  SET  should  be  USED  or  UPDATED  by  sone  PROCESS. 

4>  Every  ENTITY  should  be  USED  or  UPDATED  by  soae  PROCESS. 

5)  Every  ELEMENT  in  an  ENTITY  should  serve  at  least  one 
pu  rpose ; 

- IDENTIFIER  of  the  ENTITY 

- USED  by  soBP  PROCESS,  or 

- UPDATED  by  some  PROCESS. 

Processinq  statements  in  which  GROUPS  appear  should  apply 
to  at  least  one  ELEMENT  in  the  GROUP. 

T)  Every  ELEMENT  CONTAINED  in  an  INPUT  should  be  USED  i ii  some 

wa  V . 

B)  Every  ELEMENT  CONTAINED  in  an  ENTITY  should  serve  a 
purpose . 

9)  Every  ELEMENT  CONTAINED  in  an  OUTPUT  should  be  DERIVED  by 
some  PROCESS. 

101  ELEMENT  CONTAINED  in  an  INPUT  should  not  be  DERIVED. 

11)  An  ELEMENT  should  only  be  DERIVED  once. 

12)  Every  ELEMENT  USED  by  a PROCESS  should  be  available  from 
soae  source; 

i)  INPUT 

ii)  DERIVED  by  some  other  PROCESS 

iii)  From  an  ENTITY. 


2.5  System 

The  complete  specification  of  requirements  for  the  tarqet  systaa 
requires  statement  of  parameters  that  specify  the  volume  of  work 
that  the  system  will  have  to  do  and  the  amount  of  resources  that 
it  will  require.  Two  types  of  data  should  be  given. 

Si7e  - number  of  members  in  each  SET,  number  of  repetitions 

in  each  repeatinq  GROUP  in  an  INPUT,  etc. 

Volume  - number  of  instances  of  INPUTS  and  OUTPUTS,  number  of 
times  PROCESSES  will  be  executed,  etc.  in  a qiven 
period  of  time. 

In  URL,  the  parameters  which  characterize  size  are  called 
SYSTEM-PARAMETERS;  they  can  be  name  symbolically  and  their 
values  expressed  numerically. 

2.5.1  System  ^ze  Ob  1ects 

SYSTEM- PARAMETER  - an  object  which  affects  the  size  of  the 

system.  It  is  given  a name  and  may  be 
qiven  a numeric  value. 

■’’NTERVAL  - an  object  representinq  some  time  period 

such  as  a week,  year,  millisecond, 
planning  period,  etc. 
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2.5.2  Systen  Si^e  Rglationshics 


VALOFS 

A SYSTEH-PAPAMETEP  Bay  have  a VALUE,  or  a range  of  VALUES.  An 
ELEMENT  may  also  have  a VALUE  or  range  of  VALUES  associated  with 
it . 


CARCINALTTY 

An  ENTITY,  or  SET,  or  RELATION  may  have  a CARDINALITY. 

CONNECTIVITY 

A RELATION  may  have  a CONNECTIVITY  defined  by  specifying  two 
SYSTEM-PARAMETERS. 


HAPPENS 

An  INPUT,  OUTPUT,  EVENT,  or  PROCESS  may  HAPPEN  a 
SYSTEM-PAR AKB'^ER  (number)  of  times  in  a given  INTERVAL. 


CONSISTS 

A SET  may  CONSIST  of  a SYSTEM-PARAMETER  (number)  of  ENTITIES, 
INPUTS,  or  OUTPUTS.  An  INPUT,  OUTPUT,  ENTITY,  or  GROUP  may 
CONSIST  of  a SYSTEM-PARAMETER  (number)  of  GROUPS  and/or 
ELEMENTS.  An  INTERVAL  may  CONSIST  of  a SYSTEM-PARAMETER 
(number)  of  INTERVALS. 


2.5.3  System  Size  Syntax  and  Semantics 

The  ob-jects  and  relationships  involved  in  describing  system  size 
are  shown  pictorially  in  Figures  2.5.1,  2.5.2  and  2.5.3,  and  in 
tabular  form  in  Table  2.5.1. 

The  VALUE  or  VALUES  associated  with  a SYSTEM-PARAMETER  or 
ELEMENT  must  be  numeric  and  once  a VALUE  (or  VALUES)  has  been 
assigned,  no  other  VALUES  may  be  given  to  it. 

CARDINALITY  specifies  a number  of  occurrences.  With  respect  to 
SETS,  it  specifies  the  number  of  ENTITIES,  INPUTS,  or  OUTPUTS 
that  may  be  CONTAINED  in  the  SET  at  any  one  time.  With  respect 
to  ENTITIES,  i+-  specifies  the  number  of  occurrences  of  a 
particular  ENTITY  in  the  system  at  any  one  time.  With  respect 
to  ’’ELATIONS,  it  specifies  the  number  of  connections  made 
between  ENTITIES  via  a particular  RELATION.  A particular 
ENTITY,  SET,  or  RELATION  may  have  only  one  CARDINALITY. 
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CONNECTIVITY  specifies  the  structure  and  magnitude  of  a 
RELATION.  A particular  RELATION  may  have  only  one  CONNECTIVITY. 

The  HAPPENS  statement  specifies  the  number  of  occurrences  of  an 
INPUT,  OUTPUT,  EVENT,  or  PROCESS  in  a given  time  interval.  A 
particular  INPUT,  OUTPUT,  EVENT,  or  PROCESS  may  have  only  one 
HAPPENS  statement. 

The  CONSISTS  statement  used  in  conjunction  with  a SYSTEM- 
PARAME'^’ER  specifies  that  for  each  occurrence  o£  a given  SET, 
e.q.,  the  data  CONTAINED  in  it  occurs  the  designated  number  of 
times.  Any  particular  data  object  may  only  consist  of  another 
data  object,  one  given  SYSTEM-PARAMETER  number  of  occurrences. 


2.5.U  System  Si Common  Equivalent  and  Usage 

In  the  usual  methods  of  system  documentation,  description  of 
size  and  volume  aspects  are  incorporated  into  the  descriptions 
of  ether  objects  as  numerical  values. 

One  important  feature  of  URL  in  specifying  size  is  that  it 
permits,  and  in  fact  encourages,  all  such  specifications  to  be 
symbolic,  i.e.,  each  parameter  is  given  a name.  Consequently, 
all  situations  in  which  a given  parameter  appears  can  be 
collected  and  examined.  Numerical  values  need  only  be  assignei 
at  the  time  at  which  they  are  definitely  needed.  For  example, 
when  a system  is  initially  being  described,  it  may  only  be  known 
that  the  group  "job-data"  CONSISTS  of  the  element  "occupation." 
It  may  not  be  known  or  not  specified  until  much  later  that 
job-data  CONSISTS  of  3 or  6 occurrences  of  "occupation." 
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SET 


I 

1 

I 

I 


ZURDINALITT 

V 

I I 

I SYSTEM  I 
I PARAMETER  | 

I I 


♦ • 

I 

I 

1 

I 

♦ ■ 


ENTITY 


CARDINALITY 

V 

1 I 

I SYSTEM  I 

I PARAMETER  | 

i \ 


I 

I 

I 

I 

♦ - 


RELATION 


I I 
I I 
ICOMNEC-I 
ITTVITY  I 


SYSTEM 

PARAMETER 


>. 


CARDINALITY 

.--v 

I I 

I SYSTEM  I 
I PARAMETER  | 
I I 


I 

I 

I 

I 


SYSTEM 

PARASETER 


I 

I 

I 

I 


Figure  2.5.1  Relation  of  Ob-jects  to  a SYSTEM  PARAMETER 
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‘ 

HAPPENS/ 
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EVENT 


—r 

HAPPENS/ 
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I 
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I I 

) PROCESS  I 

I I 

♦ ♦ 

HAPPENS/ 
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-I  h 
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--  INTERVALS  ~ 

Figure  2.5.2  Relation  of  Objects  to  an  INTERVAL 
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♦ 

I I 

I SET  \ 

I I 

♦ 


V 

CONSISTS  OF 
^ 


I EHTIIY,  or| 
I Input,  or  I 
I DOTPUT  I 




♦ 

I ENTITY,  or  I 
I INPUT,  or  I 
J OUTPUT  I 




I I 

\ OP.OUP,  or  I 
I ELEMENT  | 

I I 

4 


V' 


CONSISTS  OF  -- 
-A 
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I GROUP,  or  I 
I ELEMENT  1 
I I 




I I 

I GROUP,  or  I 
I ELEMENT  J 

I I 




4 4 

I ENTITY,  or| 
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Figure  2.5.3  Relation  of  Objects  via  a SYSTEM- PAS AMETER 
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SYSTEM 


INTERVAL 

PARAMETER 

FREQUENCY 

VALUE 

INPUTS 

OUTPUTS 

CONSISTS  OF 

CONSISTS  OF 

HAPPENS/ 

TIMES 

HAPPENS/ 

TIMES 

SETS 

ENTITIES 

RELATION 

CARDINALITY 
CONSISTS  OF 

CARDINALITY 
CONSISTS  OF 
CONNECTIVITY 
CARDINALITY 

VOLATILITY- 
SET  * 

VOLATILITY- 
MEMBER  ♦ 
VOLATILITY  * 

GROUPS 

ELEMENTS 

CONSISTS  OF 

VALUE 

PROCESSES 

HAPPENS/ 

TIMES 

EVENTS 

HAPPENS/ 

TIMES 

INTERVAL 

SYSTEM- 

CONSISTS 

OF 

CONSISTS  OF 

VALUE 

PAEAMETEP 


* comment  entry 


URL 


St  at  ements 


Table  2.5.1 

Related  to  Size  and  Volume 
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System  Size  3 utputs 

To  ottain  information  specifically  about  one  or  more 
SYSTEM-PARAMETERS,  the  FORMATTED  PROBLEM  STATEMENT  may  be 
generated.  Since  very  few  of  the  statements  inyolving 
SYSTEM-PARAMETERS  have  complementary  statements,  much  of  the 
information  presented  in  the  FORMATTED  PROBLEM  STATEMENT  will  be 
in  ccmment  format. 


2.S.6  System  Size  Completeness  Checks 
The  following  checks  can  be  made; 

1)  Every  INPUT  should  have  a HAPPENS/TIMES  st,  a t e-nent. 

2)  Every  OUTPUT  should  have  a HAPPENS/TIMHS  statement. 

3)  Every  SET  should  have  a CARDINALITY  statement. 

4)  Every  ENTITY  should  have  a CARDINALITY  statement. 

5)  Every  PROCESS  should  have  a HAPPENS/TIMES  statement. 

6)  Every  EVENT  should  have  a HAPPENS/TIMES  statement. 

7)  Every  INTERVAL  should  be  used  in  some  statement. 

B)  Every  SYSTEM-PARAMETER  should  be  used  in  some  statement. 


2.6  System- Dyna  mics 

The  description  of  the  contents  of  INPUTS,  OUTPUTS,  ENTITIES, 
GROUPS  and  structures  of  PROCESSES,  and  the  relationships  among 
these  objects  produced  up  to  this  point,  gives  a "static" 
description  of  the  system.  This  does  not  in  itself  state  the 
requirements  for  the  dynamic  behavior  of  a system.  To  do  this, 
one  must  describe  those  inputs,  conditions  and  events  which  may 
influence  what  processing  is  performed,  or  the  order  in  which  it 
is  performed. 


2.6.1  Syste  m-Dv  nami cs  Objec  ts 

CONDITION  - a statement  which  can  be  in  one  of  two  states, 

TRUE  or  FALSE  (YES  or  NO,  etc.) . The  statement 
is  given  a unique  name. 

EVENT  - an  object  used  to  describe  a happening, 

external  or  internal  to  the  system,  or  an 
occurrence  which  causes  something  else  in  the 
system  to  happen. 


2.6.2  System- Dynamics  Relationships 


CAUSES/CAUS  ED 

An  EVENT  or  TNPU'^,  or  a CONDITION  BECOMING  true  or  FALSE,  CAUSES 
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an  EVENT.  An  EVENT  is  CAUSED  by  an  EVENT,  an  INPUT,  or  a 
CONDITION  BECOMINO  TRUE  or  FALSE. 


INC  EPTION-CA  USES/ON  INCEPTION 

INCEPTION  of  a PROCESS  CAUSES  an  EVENT,  or  an  EVENT  occurs  ON 
INCEPTION  of  a PROCESS. 


I NT  EPPUPTS/IN'^E  ERUPTED 

A PROCESS,  EVENT  or  INPUT,  or  a CONDITION  BECOMING  TRUE  or 
FALSE,  INTEPRUPTS  a PROCESS.  A PROCESS  is  INTERRUPTED  by  a 
PROCESS,  EVENT  or  INPUT,  or  by  a CONDITION  BECOMING  TRUE  or 
FALSE. 


MAKE5/KADE 

An  EVENT,  INPUT  or  PPOCESS  MAKES  a CONDITION  TRUE  or  FALSE.  A 
CONDITION  is  MADE  TPUE  or  FALSE  by  an  EVENT,  INPUT  or  PROCESS. 


TERMINATES/TERMINATED 

A PROCESS,  EVENT  or  INPUT,  or  a CONDITION  BECOMING  TRUE  or 
FALSE,  TERMINATES  a PROCESS.  A PROCESS  is  TERMINATED  by  a 
PPOCESS,  EVEN”"  or  INPO'^,  or  by  a CONDITION  BECOMING  TRUE  or 
FALSE. 


TERMINATION -CAUSES /ON  '"ERMI NATION 

■TERMINATION  of  a PROCESS  CAUSES  an  EVENT,  or  an  EVENT  occurs  OS 
TERMINATION  of  a PROCESS. 


TRIGGER  S/TRIGGERED 

A PROCESS,  EVENT  or  INPUT,  or  a CONDITION  is  BECOMING  TRUE  or 
FALSE,  TRIGGERS  a PPOCESS.  A PROCESS  is  TRIGGERED  by  a PROCESS, 
FVFNT  or  INPUT,  or  by  a CONDITION'S  BECOMING  TRUE  or  FALSE. 


WHILE 

A CONDITION  may  be  TRUE  WHILE  or  FALSE  WHILE  some  criteria  holi. 

2.6.3  System-Dvnaiiics  Synta  x and  Seeantics 

The  oblects  and  relationships  involved  in  describing  systee 
dynamics  are  shown  pictorially  in  Figure  2.6.1  and  in  tabular 
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form  in  Table  2.6.1. 


INCEPTION  or  TERMINATION  of  a PROCESS  may  CAUSE  any  number  of 
'=’VFNTS.  Similarly,  an  EVENT  may  occur  ON  INCEPTION  or  ON 
TERMINATION  of  any  number  of  PROCESSES.  The  INCEPTION  of  a 
PROCESS  is  its  beqinninq,  TERMINATION  is  the  completion  of  the 
PROCESS  . 

Any  number  of  EVENTS,  INPUTS,  and/or  CONDITIONS  may  CAUSE  and 
EVENT.  However,  a separate  statement  is  required  for  each 
CONDITION  involved.  Similarly,  any  number  of  EVENTS  may  be 
CAUSED  by  a given  collection  of  EVENTS,  INPUTS,  and/or 
CONDITIONS. 

Any  number  of  EVENTS,  INPUTS  and/or  PROCESSES  may  MAKE  a 
CONDITION  TRUE  or  FALSE.  Any  number  of  CONDITIONS  may  be  MADE 
TRUE  or  FALSE  by  a given  collection  of  EVENTS,  INPUTS  aud/or 
’PROCESSES.  Only  one  of  the  values,  TRUE  and  FALSE,  may  be  used 
in  a given  MAKES  of  MADE  statement.  The  term  MAKES  implies 
setting  the  value  or  a CONDITION. 

Any  number  of  PROCESSES,  EVENTS,  INPUTS  and/or  CONDITIONS  may 
TRIGGER,  INTERRUPT  or  TERMINATE  a given  PROCESS.  Any  number  of 
PROCESSES  may  be  TRIGGERED,  INTERRUPTED  or  TERMINATED  by  a given 
collection  of  PROCESSES,  EVENTS,  INPUTS  and/or  CONDITIONS.  To 
TRIGGER  a PROCESS  is  to  initiate  it.  A PROCESS  is  INTERRUPTED 
if  it  is  eligible  to  he  resumed  later,  while  it  is  TERMINATED  if 
it  is  ended  (whether  complete  of  not)  and  is  not  to  be  resumed. 

A CONDITION  may  only  have  one  WHILE  statement,  which  is 
expressed  as  a comment  entry.  Should  more  than  one  be  specified 
for  a given  CONDITION,  the  comment  entries  will  be  combined  (the 
second  added  to  the.  end  of  the  first  and  so  on)  . 
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PROC^S 

EVENT 

PROCESS 

TRIGGERS 

TERM  INATES 

INTERRUPTS 

TRIGGERED  BY 
TERMINATED  BY 
INTERRUPTED  BY 

INCEPTION-CAUSES 

TERMINATION-CAUSES 

TRIGGERED  BY 

TERMINATED  BY 

INTERRUPTED  BY 

EVENT 

TRIGGERS 

TERMINATES 

INTERRUPTS 

ON  INCEPTION  OP 

ON  TERMINATION  OF 

CAUSES 

CAUSED  BY 

CONDITION 

BECOMING  {TRUE} 

TRIGGERS  {FALSE} 

BECOMING  (TRUE) 

TERMINATES  {FALSE} 

BECOMING  {TRUE} 

INTERRUPTS  {FALSE} 
{TRUE} 

MADE  {'■AISE}  BY 

BECOMING  (TRUE) 

CAUSES  {FALSE} 

{TRUE) 

MADE  {FALSE)  BY 

INPUT 

TRIGGERS 

TERMINATES 

INTERRUPTS 

CAUSES 

Table  2.  6.  1 

ORL  Statements  for  Describing  System- Dyanmics 
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CONOI''’ION 

INPUT 

PROCESS 

(TRUE) 

MAKES  --  {FALSE} 

TRIGGERED  WHEN 

{TRUE} 

--UECOMES  {FALSE} 

TRIGGERED  BY 

TERMINATED  BY 

INTERRUPTED  BY 

TEP'IINA"’ED  WHEN 

{TRUE} 

--BFCOMES  {FALSE} 

INTERRUPTED  WHEN 

{TRUE} 

--BECOMES  {FALSE} 

EVENT 

{'"RUE} 

MAKES  --  {FALSE} 

CAUSED  WHEN  — 

{TRUE} 

BECOMES  {FALSE} 

CAUSED  BY 

CONDITION 

WHILE  * 

{TRUE} 

MADE  {FALSE}  BY 

INPUT 

{TRUE} 

MAKES  --  {FALSE} 

* comment  entry 


only 


Table  2.6.1  (Continued) 
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2.6,U  S vstem-Dy  nawics  Common  Equivalent  s an;1  Usage 

As  is  the  case  with  system  si2e,  description  of  system  dynamics 
aspects  are  often  not  stated  explicitly  bvit  ate  incorporated 
into  the  descriptions  of  other  objects.  In  some  cases,  this 
type  of  information  is  presented  by  decision  tables  or  by 
decision  blocks  in  flow  charting  methods. 

Since  decision  tables  present  a plan  of  "action”  based  on 
conditions  and  events,  they  may  be  given  in  the  PROCEDURE 
statement  for  the  appropriate  PROCESS,  it  desired. 

A list  of  EVENTS  TRIGGERING  a PROCESS  implies  that  each  one  of 
the  EVENTS  TRIGGERS  the  PROCESS.  Since  an  EVENT  occurs  at  an 
instant  in  time,  the  user  should  not  need  to  say  that  a 
combination  of  EVENTS  TRICGERS  a PROCESS,  since  this  would 
require  that  all  the  EVENTS  occur  simultaneously. 

Even  though  there  is  no  way  to  state  explicitly  that  a 
combination  of  CONDITIONS  TRIGGERS  a PROCESS,  this  may  easily  be 
handled  by  defining  a new  CONDITION  to  represent  the 
combination.  For  example,  if  PROCESS  P 1 is  TRIGGERED  when 
CONDITION  Cl  is  true  and  CONDITION  C2  is  FALSE,  the  user  may 
wri  '•e; 


CCNDITION  C3; 

TRUE  WHILE; 

Cl  AND  NOT  C2; 

PROCESS  PI; 

TRIGGERED  WHEN  C3  BECOMES  TRUE; 

Any  EVENT  or  CONDITION  that  affects  the  system's  operation, 
should  be  defined. 


2.6.5  System- Dynamics  Outputs 

The  PORMATTED  PROBLEM  STATEMENT  may  be  generated  to  obtain 
information  about  one  or  more  CONDITIONS  or  EVENTS. 

The  PROCESS  CHAIN  report  will  show  structures  of  EVENTS  and 
PROC'^SSES  connected  by  TRIGGERS  and  TRIGGERED  BY  statements. 


2.6.6  System-Dynamics  Completeness  Checks 

1^  Every  EVEN"^  should  he  associated  with  at  least  one 
CONDITION  or  PROCESS. 

2)  Every  CONDITION  should  be  associated  with  at  least  one 
EVENT  or  PROCESS. 

3)  Every  CONDITION  should  have  a TRUE  WHILE  or  a FALSE  WHILE 
statement . 
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2.7  Svstea  A rch itec: t ure 

ThP  system  architecture  description  deals  with  the  physical 
aspects  of  an  information  processing  systea. 


2.7.1  System  Architecture  Oblects 


PROCESSOR  - 


RESOURCE  - 


UNI  I - 


an  ob-ject  that  can  "perform’'  a PROCESS. 

something  that  the  physical  elements  in  the 
target  systea  consume  in  order  to  carry  out 
information  processing  functions. 

an  oh-|ect  used  to  measure  RESOURCES. 


RES OURC E-US AOR-  used  to  define  a measure  of  the  RESOURCE 
PARAMETER  - usage  for  a PROCESS. 


2.7.2  S ystem  Architecture  R elationships 

CHNSUMFS/CONSUM  ED  BY  - A RESOURCE  Bay  be  CONSUMED  BY  a 

PROCESSOR,  and  a PROCESSOR  May 
CONSUME  an  amount  of  RESOURCE  PEP 
RESOURCE-USAGE-PAH  A MEIER. 

PERFOPMS/PEPFOnflED  BY  - A PROCESSOR  may  PERFORM  a PROCESS, 

and  a PROCESS  may  be  PERFORMED  BY  a 
PROCESSOR. 


MEA  SURFS/ME  A SUR  ED  IN  - 


'’ESOUPCE-US  AGE/RESDURCE- 
USAGE-P  APAMETE’’-VALUF  - 


A UNI”^  may  MEASURE  a RESOURCE,  and 
a RESOURCE  may  be  MEASURED  IN  a 
UNIT. 

A PROCESS  may  haye  a RESOURCE- 
USAGE-  PAP  A METER-  VALUE  associated 
with  a RESOURCE-USAGE-PARA  METER. 


2.7.3  System  Architecture  Syntax  and  Semantics 

'’’he  objects  and  r*^l ationshi ps  involved  in  describing  system 
architecture  are  shovn  in  Table  2.7.1. 

A PROCFSS  may  have  an  arbitrary  number  of  RSSOURCE-USAGE- 
PAPAMETER  and  R ESOU  PCE-USAG  E-PAPA  METER- VALU  E pairs.  (But  there 
can  only  be  at  most  one  such  pair  for  a particular 
RESOURCE-USAGE-PARAMETEP.)  This  pair  is  used  to  describe  the 
expected  resource  consumption  by  the  execution  of  the  PROCESS  in 
a I’ROCESSOR  indeoendent  manner.  The  CONSUMES  statement  in  the 
PROCESSOR  section  specifies  the  name  and  amount  of  RESOURCES 
that  are  consumed  per  RFSOU RCE-USAGE-PA RAMETER  of  the  PROCESS  it 
oerforms.  This  measure  is  translated  to  a resource  consumption 
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value  by  multiplyinq  the  PESOURCF-USAGE-PAR AMETER- VALUE  with  the 
resource-consum  pt  io  ri-va  lue  foe  the  RESO  UFCE-USAGE-PARAMETER  in 
the  CONSUMES  statement  of  the  PROCESSOR.  For  example,  suppose 
that  there  is  a PROCESS  "PI,''  and  a PROCESSOR  "PRl,”  and  that 
the  RESOURCE  in  question  is  "CPU-TIME"  (measured  in  UNIT  of 
"MICRO-SECONDS"),  as  in  Fiquee  2.7.1. 


RESOUPCE- 

OSAGE- 


PROCESSOR 

RESOURCE  UNIT 

PARAMETER 

PROCESS 

PROCESSOR 

SUBPARTS 
PART  OF 

CONSUMES 

CONSUMES 

PER 

PERFORMS 

RESOURCE 

CONSUMFD 

BY 

MEASURED 

IN 

UNIT 

MEASURES 

PESCUPCE 

USAGE 

PARAMETER 

RESOURCE- 
USAGE- 
PARAMETER 
VALUE  FOB 

PROCESS 

PERFORMED 

RESOURCE- 

USAGE 

Table  2.7.1 

System  Architecture  Relationships 


PROCESS  P 

1; 

PFSOUP 

CE-U 

SAGE: 

100 

PROCESS  P 

2; 

RE SOUP 

CE-U 

SAGE; 

200 

PROCESSOR 

PF1 

* 

PFFFOR 

MS  P 

1; 

CONSUM 

ES  C 

PU-TI 

ME 

AT 

STAT 

EMEN 

TS; 

FOR  NO-OF-STATEMBNT; 

FOR  NO-OF-STATEMENT 

RATE  OF  20  PER  NO-OF' 


Figure 
Example  of  URL 
PPOCFSSOR  and  its 


2.7. 1 

statements  for 
RESOURCE-usage. 


Here  "NO-OF- STA TEMF NT"  is  a R ESOURCE-US AGE-P ARAM ETER . The 
PROCESS  called  PI  has  a value  of  100  for  this  parameter.  One 
possible  interpretation  of  this  statement  is  that  the  relative 
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Ufficultv  or  cora’ilpxitv  of  the  PROCESS  is  such  that  it  woull 
♦•ake  100  "st  atpinen'’ s'*  on  a hypothetical  processor.  Other 
'’POCESSes  may  he  qiven  values  for  the  same  RESOU  RCE- USA  OE- 
PARAMETFP.  '=’or  example,  PROCESS  P2,  which  is  considered  twice 
as  difficult  or  complex,  is  qiven  the  value  200  for  this 
P’='SOUPrS-US  AOE- PARA  METER.  Note  that  the  RESOUPCE-USAGE- 
PA'?AMETER  and  its  value  are  meant  to  be  PROCESSOR  independent. 
They  are  used  to  record  estimation  of  R ESOURCE- USAG  E independent 
of  what  PROCESSOR  performs  the  particular  PROCESS. 

In  the  PROCESSOR  section,  the  CONSUMES  statement  is  used  to 
record  the  resource-consumption- value  for  a PESO URC E- US  AG E- 
oARAMETER.  In  the  examnle  of  Figure  2.7.1,  20  is  the 
resource-consum ption-value  of  the  PROCESSOR  "PP1"  for  the 
PSSOURCE-US  AGE- PARA ''ETEF  "N  O-OF-ST  ATEMENT.  " "M ICRO- S EC  ON  DS  " is 
the  name  of  the  that  is  used  to  measure  the  RESOURCE  called 

"CP  U-TT  ME. " 

This  statement  may  be  interpreted  as  saying  that  the  PROCESSOR 
"PP1"  will  consume  20  microseconds  of  CPU  time  per  "number  of 
statements"  (giver,  in  the  PROCESS  description)  whenever  it 
nerforms  a PROCESS.  In  this  example,  2,000  (100  x 20) 
microseconds  of  CPU  ♦:ime  i.s  consumed  by  PROCESSOR  "PR1"  whenever 
i *:  performs  '’POCESS  "Pi,"  and  u,000  (200  x 20)  microseconds  for 

"?2  . " 


It  is  possible  ro  associate  more  than  one  RESOURCE-USAGE- 
PA'^'AMETEP  (and  its  value)  for  a PROCESS.  It  may  be  used  to 
allow  for  the  possibility  of  employing  two  completely  different 
types  of  proces.sors  (like  a computer  and  a person)  to  perform 
•■he  PROCESS.  In  this  wav,  the  decision  as  to  what  PROCESSOR  to 
use  for  a narticular  PROCESS  may  be  delayed  as  necessary  and 
cha  nqin  g ^t  he  PPOCFS.'^OR  for  a PROCE.SS  once  it  is  decided  is 
easier,  ’uaving  more  than  one  pair  of  RESOU  RCE-US  AGE-PA  RAMETEEs 
and  its  value  mav  also  be  used  to  describe  resource  consumption 
independen*- 1 V for  more  than  one  resource.  Only  the  resource 
consumption  value,  which  ha.s  the  same  RESOURCE- USAS  E-PA  PA  METER 
in  both  PROCESS  and  PROCESSOR  sections,  is  taken  as  contributing 
to  the  actual  resource  consumption.  If  there  are  multiple 
instances  of  such  PARAMETERS,  the  net  consumption  for  a resource 
is  the  sum  of  all  the  consumption  values. 

"he  PEP  FORM  3/?’=' ED  BY  statement  is  to  record  the 
relationship  he'-ween  a PROCF.ss  and  the  PROCESSOR  that  performs 
(i.e.,  carriers  out,  does,  etc.)  the  PROCESS.  A PROCESSOR  can 
perform  more  than  one  PPOCESSes,  but  a PROCESS  can  be  performed 
bv  only  one  ’’RgcE'^SOR. 

The  MEA  SU^’ES /ME  ASUF  FD  IN  statement  is  to  define  relationships 
between  a UNIT  and  a RESOURCE.  A UNIT  may  measure  more  than  one 
RESOURCE,  but  a PFEOUPCE  can  be  measured  only  in  one  UNIT.  The 
UNT'*’  name  tha*-  appears  after  the  resource-consumption-value  in 
♦•he  CONSUmK'B  statemen*-  of  the  PROCESSOR  section  is  optional,  but 
if  it  is  given  it  must  be  »-he  correct  UNIT  name  for  that 


PART  I USER  REQUIREMENTS  LANGUAGE  MANUAL 


T 


IBM3  6 0/37  0/VS/TSO  UPL  HSEP'S  HANfJAL 


114 


RESOOPCE. 


2.7.4  FystPm  A rchi t ecture  Coapleteness  Checks 

"'he  completeness  checks  that,  can  be  made  for  SAP  ob-jects  are: 

1)  Every  PROCESS  should  be  PERFORMED  BY  a PROCESSOR  and  every 
PROCESSOR  should  PERFORM  at  least  one  PROCESS.  At  each 
subdivision  of  PROCESS  and  PROCESSOR  SUBPARTS/PART  OF 
structure,  the  PEPFOPtI  S/PERFORMED  BY  relationships  of  the 
subparts  should  be  consistent  with  the  rela  tionshi  p.s  of  the 
parent  ob-jects. 

2)  If  a PROCESSOR  PERFORMS  a PROCESS,  at  least  one  common 
RESOHRCE-BS AGE-PARAMETER  must  be  defined  for  the  PROCESSOR 
(via  CONSUMES  Statement),  and  for  the  PROCESS  (via 
RESOORCE-USAGE  statement). 

3)  If  a SYS7EM-PAPAHSTEP  is  used  for  FESOU  RCE- USAGE-P  AR  AM  ETF^- 
VALDE  or  in  the  CONSUMES  statement  of  the  PROCESSOR 
section,  it  must  have  a sinqle  numerical  value. 

4)  Every  UNIT  should  MEASURE  at  least  one  RESOURCE,  and  every 
RESOURCE  should  be  measured  in  a UNIT,  and  CONSUMED  BY  at 
least  one  PROCESSOR. 


2 . 8 Properties 


The  facilities  described  in  this  section  are  available  to  aid 
all  aspects  of  documentation,  communication  and  analysis.  These 
facilities  also  provide  open-ended  classification  systems  since 
these  '’qualifiers"  may  be  added  at  any  time  and  used  for 
retrieval  of  parts  of  the  problem  statement.  They  can  be  used 
to  describe  any  of  the  ob-jects  whether  in  the  organisation,  the 
target  system  or  in  the  project.  They  may  be  used  in  cases 
where  the  analyst  wishes  to  include  some  information  in  the 
documentation  where  no  formal  syntax  is  available. 


2.8.1  Properties  Ob  1 ects 

SYNONYM  - is  used  to  define  an  alternative  name  (alias) 

for  a given  named  object  in  the  URL  description 
of  the  system. 


XEYWCPD  - an  object  associated  to  one  or  more  names  for 

the  purpose  of  selection  and  analysis. 

MEMO  - an  object  which  represents  text  relevant  to  one 

or  more  other  objects. 
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ATTPIBUte  an(i  A TTPI  B UTE- VAL  UE  - objects  used  to  describe 

characteristics  of  objects  not  otherwise 
allowed  in  the  lanquage. 


sonpct 


PECUPITY  - 


TPACF-KEY  - 


an  ohiect  which  is  to  be  referenced  for  more 
information  about  an  object.  Examples  of 
SOURCES  are  interview- reports,  company 
procedure  manuals,  documents,  etc. 

an  object  which  identifies  what  points  of  the 
problem  statement  may  be  reviewed  by  what 
in  d iv  idual  s . 

an  object  which  is  used  to  correlate  objects 
which  exist  in  different  data-bases. 


2.B.2  Prooerties  Pe  lationsh  ios 


DESCRIPTION 


Any  object  defined  in  the  problem  statement  may  have  a 
DESCRIPTION,  which  consists  of  one  or  more  lines  of  narrative 
text.  s description  is  not  a URL  object  and  does  not  have  ^ URL 


SYNONYM 

Xny  type  of  object  may  have  SYNONYMS  and  a SYNONYM  may  be 
DESIGNATED  for  a aiven  object. 


ASSET 

Anv  object  which  has  a relationship  with  another  object  may  have 
an  ASSENT  statement.  An  ASSERT  statement  asserts  that  one 
object  must  have  a particular  ATTRIBUTE  and  ATTRIBUTE-VALUE  when 
related  to  another  object. 


ATT  RIBTITES 

Any  objec*-  mav  have  ATTRIBUTES  with  corresponding 
ATTRIBUTE-VALUES, 


KEYWOPDS/APPLTES 

Any  object  may  havo  KEYWORDS  associated  with  it  and  a KEYWORD 
mav  APULY  to  any  type  of  object. 
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A qiven  object  Bay  have  any  number  of  ASSERT  stateients  which 
relate  that  object  to  other  objects  having  particular  ATTRIBUTES 
and  ATTRIBUTE-VALUES. 


A given  object  may 
MEMO,  however,  may 
APPLY  to  any  number 


have  any  number  of  SEE-MEMO  statemen 
not  have  any  SEE-MEMO  statements.  A 
of  named  objects. 


ts . A 
MEMO  nay 


An  object  may  have  any  number  of  SOURCES  and  any  SOURCE  may 
APPLY  to  any  number  of  objects. 


An  object  may  have  any  number  of 
APPLY  to  any  number  of  objects. 


SECURITIES  and 


any  SECURITY  may 


An  object 
may  APPLY 


may  have  any  number  of  TRACE-KEYS 
to  any  number  of  objects. 


and  any  TRACE-KEY 
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Any  Type 
of 


Object  * 

KEYWORD 

MEMO 

ATTRIBUTE 

Any  Type 
o f 

Obiect  * 

KEYWORD 

IS 

SEE- MEMO 

ATTRIBUTE 

IS 

KEYWCRP 

AopL lES 

-T^O 

• 

SEE-MFMO 

ATTRIBUTE 

I S 

MEMO 

APPL  lES 

TO 

KEYWORD 

IS 

ATTRIBUTE 

r s 

ATTPTBUTE 

KEYWORD 

IS 

SEE-MEMO 

ATT  PI  PU'^E 
VAL  UE 

KEYWORD 

IS 

SEE- MEMO 

SOURCE 

APPLIES 

TC 

KEYWORD 

IS 

SEE- MEMO 

ATTRIBUTE 

IS 

SEC  UPITY 

APPLI’^'S 

o 

KEYWORD 

IS 

SEE- MEMO 

ATTRIBUTE 

IS 

TRACE-KEY 

APPLIES 

TC 

KEYWORD 

IS 

SEE- MEMO 

ATTRIBUTE 

IS 

ATT^  rPU^E 
VALUE 

- 

SOURCE 

SECURITY 

TRACE-KEY 

IS 

Any  Type 

o f 

ATTF  IRUTr 

IS 

SOURCE 

IS 

SECURITY 

IS 

TRACE-KEY 

IS 

Obi  ec»- 

KEYWORD 

AT . R IBUT  E 

IS 

SOURCE 

IS 

SECURITY 

IS 

TRACE-KEY 

rs 

MEMO 

ATTP  IBU" 

IS 

SOURCE 

IS 

SECUE ITY 

IS 

TRACE-KEY 

IS 

A'^TRTPUTE 

SOURCE 

IS 

SECUR ITY 

IS 

TRACE-KEY 

IS 

AT'^RIPU'^E 

VALUE 

SOURCE 

IS 

SECURITY 

IS 

TRACE-KEY 

IS 

SOURCE 

ATTR IBUTE 

IS 

S ECURITY 

IS 

TRACE-KEY 

IS 

SECURITY 

ATTR  IBtfTF 

IS 

SOURCE 

IS 

TRACE-KEY 

IS 

TRACE-KEY 

ATTR IBUTE 

IS 

SOURCE 

IS 

SECURITY 

IS 

♦ oHhpr  than  KEYWOPF,  MEMO,  ATIPIEOTE,  ATTR IBUT  E-VALUE,  SOURCE 
or  SECURITY 

Table  2.8.1 

UPL  Statements  for  Describing  Properties 
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2 . fl  . 4 Properties  Eguivalenta  and  Usage 

The  TFSCHIPTION  associated  with  a given  oh-|ect  is  analogous  *-o 
any  text  description  presented  in  most  docuoienta tion  methods. 

It  may  contain  any  tables,  charts  or  figures  which  can  be 
displayed  by  the  output  device. 

A URL  STNONVI  has  the  same  meaning  as  comnionly  used.  Its  two 
ma1or  uses  in  URL  are: 

1)  To  reduce  the  number  of  characters  used  in  specifying  the 
problem  statement.  This  can  be  accomplished  by  assigning  a 
very  short  synonym  to  each  user  defined  name  as  it  is 
defined . 

2)  To  allow  different  problem  definers  to  reference  the  same 
ob-ject  by  different  names. 

KEYWORDS  may  he  used  to  logically  group  several  objects  for 
retrieval  and  analysis  purposes.  For  example,  to  generate  UKA 
reports  for  only  those  PROCESSES  which  were  to  run  in  batch 
mode,  each  of  the  PPOCESSES  could  have  the  following  KEYWOPD 
statement: 

KEYWORD:  BATCH  ; 

Using  the  KEY=  facility  in  the  NAME-GEN  command,  all  the 
PROCESSES  with  a KEYWORD  'BATCH'  could  be  retrieved.  Any 
desired  outputs  could  be  produced  by  UR  A at  this  point. 

A'^TRTBUTES  may  also  be  thought  of  as  qualifiers.  For  example, 
to  present  mode  and  length  information  about  an  ELEMENT,  the 
following  ATTRIBUTES  statement  might  be  used: 

ATTRIBUTES:  MODE  NUMERIC, 

LENG'^’H  8 ; 

The  AT'^'FIBUTE  statement  can  be  used  to  fill  any  number  of 
requirements  for  specifying  characteristics  of  objects.  For 
PROCESSES,  processing  mode,  duration  might  be  given;  for  INPUTS 
and  OUTPUTS,  format  or  size  might  be  given;  etc. 

The  ASSERT  statement  may  be  used  to  present  more  information 
about  an  existing  relationship.  For  example,  if: 

PROCESS:  get-names  DERIVES  name  USING  number; 

an  appropriate  ASSERT  relationship  would  be; 

ASSERT  name  type  char,  number  type  integer; 

URL  provides  the  facility  in  KEYWORD  and  ATTRIBUTE  statements 
for  the  classif icaf ion  of  objects  by  a criteria  which  can  be 
defined  and  expanded  as  the  project  progresses.  The  additional 
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information  can  bp  added  at  any  time  during  the  project  without 
disturbing  thp  iata  gathered  up  to  that  point. 

SECURITY  and  SOURCE  refer  to  the  definition  of  the  objects#  not 
to  the  r.ecuri'-y  of  data  or  source  of  data  in  the  target  system. 

The  T’»ACE-KEY  statement  is  used  to  correlate  objects  contained 
in  different  data-bases.  The  security  level  in  a logical  system 
design  data  base  and  a security  level  number  in  a physical 
system  design  data-base  may  both  have  the  statement: 

TRACE-KEY:  security- level- key ; 


2.  S . 5 P rone  r tie  s Ou  t pu  ts 

■"hp  DICTIONARY  report  oresents  SYNONYKS  , the  OESCRPITIDN  and 
KEYWORDS  for  each  name  given  as  input. 

"he  NAME-OEN  command  can  retrieve  all  names  with  a particular 
KEYWORD  value  bv  using  the  KEY  parameter.  Reports  may  then  be 
generated  for  the  selected  names  by  utili'zing  the  default 
facilities  of  UHA. 

"^he  ATTPTSUTB  report  presents  information  about  ATTRIBUTES  in 
the  problp®  statement  by  presenting  those  objects  the  particular 
ATTRIBUTES  ar®  associated  with  and  corresponding 
AT-rRIBUTE-yALUES. 


2.B.f  Proper  ties  Completeness  Checks 


None  of  the  proper'-ies  are  "necessary"  for  a complete 
description.  It  is  up  to  the  organization  to  impose  any 
regiiirements  for  what  type  of  properties  are  to  be  incorporated 


in 

the  docu 

However,  ev 

once . 

1) 

Every 

2) 

Every 

?) 

Ev  ery 

4) 

Every 

Every 

6) 

Ev  ery 

ob  ject 

KEYWORD  should  APPLY  to  at  least  one  object. 
ATTPIBU'^E  should  APPLY  to  at  least  one  object. 

MEMO  should  APPLY  to  at  least  one  object. 

SOURCE  should  be  the  source  for  at  least  ona  object. 
SECURITY  should  be  referenced  in  at  least  one  object 
TRACE-KEY  should  be  referenced  by  at  least  one 


2.°  Pro iect  Management 

All  object  and  statement  facilities  in  UFL/URA,  which  are 
intended  to  imorove  organization  and  management  within  the 
prcjec’-  and  present  informa '•ion  about  the  project  describing  the 
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system,  is  referrerl  to  as  Project  Management, 


2.9.1  Project  Management  Object.^ 

PRCPIEK-DFF  IN'^P  - an  object  responsible  for  the  URL 

description  of  one  or  more  of  the  objects 
being  described.  Usually,  the  URL  names 
will  be  the  name  of  a person  in  the  form 
normally  used  in  the  organization. 

MAILBOX  - an  object  which  identifies  an  address  by 

which  information  may  be  sent  to  a 
particular  PPOBL EM-DEFINEE . In  time 
sharing  systems,  which  provide  such  a 
service,  the  MAILBOX  would  be  the 
PPOBL BM-DEFINER' s ID. 


2.9.2  P rogec t Management  Relationships 


P ES PONS IBLE- PRO BLEM-DEFINER /RE SPONSIBLE  FOP 

A PFOBLEM-DEFIN ER  may  be  RESPONSIBLE  for  the  description  of  any 
other  object,  and  any  object  may  have  a 
RESFONSIBLF-PPOBLEM-DFFINEP  . 


MAILBOX /APPLIES 

A PROBLEM-DEFINER  may  have  a MAILBOX  and  a MAILBOX  may  APPLY  to 
a PROBLEM-DEFINER. 


2.9.3  Project  Management  Syntax  and  Semantics 

The  objects  and  relationships  involved  in  describing  the  project 
management  aspect  of  a system  are  shown  pictorially  in  Figure 
2.9.1  and  in  tabular  form  in  Table  2.9.1. 

The  RESPONSIBLE-PFOBLEM-DEFINER  statement  implies  that  the  given 
PROBLEM-DEFINER  accepts  ^responsibility  for  the  URL  description 
of  the  designated  object:  it  is  assumed  that  any  questions 
concerning  this  description  can  be  handled  by  the 
PROBLEM-DEFINER.  A given  object  may  have  only  one 
RBSFONSBILE-PROBLEM-DFPINER,  hut  a PROBLEM-DEFINER  may  be 
RESPONSIBLE  for  many  object  descriptions. 

A PROBLEM-DEFINER  may  have  only  one  MAILBOX,  but  a MAILBOX  may 
APPLY  to  any  number  of  PPOBLEH-DEFINERS . 
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2.9. '5  Proiec t !1anaqewent  Outputs 

Information  relevant  to  proiect  management  can  be  presented  in  a 
POPMAT'^ED  PPO'ILSM  STATEMENT  for  appropriate  PROBLEM-DEFINEPS  and 
MAILBOXES. 

The  DATA  BASE  SBMMAPY  report  gives  the  number  of  each  objects  of 
each  type  that  have  been  defined,  and  how  many  have  SYNONYMS  and 
DESCPTPTIONS . This  report  can  be  used  by  the  project  leader  to 
review  the  degree  of  progress  in  the  project. 


2. ‘^.6  project  Management  Completeness  C hecks 

1)  Every  problem- DEFINEP  should  be  RESPONSIBLE  for  at  least 
or p ob iect . 
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2)  Every  oh-ject  should  have  one  and  only  one 
RESPON  SIBL E-PROBLEM-DEE  I NEF. 

3)  Every  MAILBOX  should  APPLY  to  at  least  one  PRO  BLEU- 0 EFINER . 

4)  Every  PROBLFM-DEFINEP  should  have  a MAILBOX. 


3.  URL  SYNTAX  AND  SEMANTICS  BY  TYPE  OF  OBJECTS 


The  full  and  detailed  syntax  of  URL  is  contained  in  Pact  II  of 
this  document.  There,  Section  3 contains  a sumBiary  of  the 
statements  in  each  section  with  the  sections  in  alphabetical 
order.  Section  4 contains  the  description  of  each  statement. 
Within  a section,  statements  appear  in  alphabetical  order  by 
statement  name. 


In  this  section  the  Sections  and  Statements  are  present-ad  in  a 
different  order.  The  paragraphs  following  each  statement 
describe  the  statement  and  give  the  syntax  for  each  statement 
and  an  example  of  their  usage. 

As  in  Section  2,  the  explanations  of  URL  statements  include 
three  levels  of  precision: 


"mu  St " 


denotes  that  thio  is  checked  by  lira  and  not 
entered  into  the  data-base  unless  correct. 


"should"  - 


"implies"  - 
and 
"ma  y" 


denotes  that  this  is  not  checked  by  UFA  before 
stored  in  the  data-base  but  is  necessary  for  a 
complete  description  of  the  target  system. 

Some  of  tae.se  "completeness"  checks  are  made 
when  producing  UFA  reports  and  warning  messages 
are  produced.  Others  can  be  made  by  the 
analyst  using  UFA  reports. 

denotes  the  semantic  meaning  of  the  statement. 
This  is  not  checked  by  ORA  nor  necessary  for  a 
complete  description.  Interpretation  is  to  be 
decided  by  the  Problem  Definer  and 
organization . 


The  UPL  reserved  word  in  parentheses  after  the  syntax  notation 
for  a statement,  specifies  an  acceptable  abbreviation  for  the 
long  form  of  the  statement’s  reserved  word(s). 


The  word  "section"  is  used  in  UPI  to  denote  a number  of 
statements  and  in  this  paper  to  denote  a number  of  paragraphs. 
To  avid  confusion,  the  fist  letter  will  be  capitalized  when 
referring  to  a URL  Section. 


3 . 1 Ord^  of  Presentation 

3.1.1  Order  of  the  Sections 
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The  rpst  of  Spcfior.  3 specifies  the  complete  syntax  of  the 
statements  for  each  UPL  Section.  The  URL  Sections  are  present?'! 
in  the  order  shown  in  “^able  3.1. 


3.1.2  Order  of  Stat  eaents  Within  a Sect  ion 

The  facilities  of  UPL  to  state  an  information  processing  problem 
have  been  described  in  section  2 in  order  by  a sequence  of 
different  aspects.  The  particular  sequence  chosen  is  a natural 
one  in  which  to  learn  the  language.  It  is  also  a natural  one 
when  the  problem  is  being  defined  in  top-down  fashion.  In  this 
section,  within  each  URL  Section  description,  the  corresponding 
UPL  statements  are  ordered  according  to  the  aspect  of  the  system 
description  to  which  the  Statements  apply.  The  aspects  of  the 
system  description  are  given  in  the  following  order: 

System  >='low 
System  Structure 
Data  Structure 
Data  Derivation 
System  Size 
System  Dynamics 
System  Architecture 
System  Properties 
Prcgect  Management 

Since  System  Property  and  Project  Management  statements  can 
appear  in  almost  every  section,  they  are  given  only  once  in  3.2. 

Regardless  of  the  order  in  which  statements  are  entered  into  the 
UPA  data-base,  they  appear  in  the  FORMATTED  PROBLEM  STATEMENT  in 
a standard  order.  The  order  is  essentially  that  followed  in 
section  2 and  summarized  in  Table  3.1.  (The  order  in  which  the 
sections  (i.e.,  the  types  of  objects)  appear  in  the  report  is 
the  one  in  which  the  types  of  objects  were  listed  in  the  file 
used  as  the  innut  to  the  NAME-GEN  command  and  to  produce  the 
FORMATTED  PROBLEM  STATEMENT.) 
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IMTEPFACE  or  PP  AL- W C FLD- ENT  TTY  3.3 

INPCT  3.4 

OfJTFOT  3.5 

ENTITY  3.6 

SET  3.7 

RELATION  3.8 

GROUPS  anil  FLEEENTS  3.9 

PROCESS  3.10 

INTERVAL  3.11 

CONDITION  3.12 

EVENT  3.13 

PROCESSOR  3.14 

RESCnpcE  3.15 

RESOURCE-USAGE- PAPA METEP  3.16 

UNIT  3.17 

PPOBLEH-DEFINER  3.18 

WEHC  3.19 

DEFINE  3.20 


ATTRI  BUTE 

ATTRIBUTE- VALUE 

CLASSIFICATION 

KEYWORD 

MAILBOX 

SECURITY 

SCUPCE 

SUBSETTING-CRITERION 

SYSTEM-PARAMETER 

TRACE-KEY 

DESIGNATE  3.21 

SYNONYM 

Table  3.1  Order  of  URL  Section 


3.2  Sta teaen ts  Peria itted  in  Alnost  Every  URL  Section 

The  URL  statements  that  may  be  allowed  in  a given  URL  Section 
are  dependent  on  the  types  of  obiects  defined  by  the  section 
header.  Where  it  is  illogical  to  say  that  an  ELEMENT  USES  a 
PROCESS,  to  state  that  a PROCESS  USES  an  ELEMENT  would  be 
all  owed . 

There  are,  however,  the  URL  statements  related  to  System 
Properties  and  project  Management  that  can  be  used  within  alnost 
any  Section.  These  statements  are  described  in  this  subsection. 

3.2.1  SYNONYM  Statement 

SYNONYMS  are  alternative  names,  or  abbreviations,  that  nay  be 
used  to  reference  a particular  object  name.  SYNONYMS  must  be 
ungiue  within  the  problem  statement,  though  an  object  can  have 
any  number  of  SYNONYMS. 
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Syntax: 


( 

! SYN)NYr.S  (SYN) ; 

j (list  of  synonym  names) 

1 

I Example: 

1 

For  a lonq  name  like  "depar  tments-and-employees , " it  may  be 
i easier  to  reference  it  by  specifying  short  synonyms: 

I SYNONYMS:  dept-emp,  de; 


I 

I 1.2.2  DESCRIPTION  Statement 

! The  DESCRIPTION  statement  allows  the  problem  definer  to  specify 

I information  about  an  object  in  a narrative  format.  There  are  no 

restrictions  on  what  is  allowed  in  the  narrative  description 
I except  that  a semi-colon  cannot  be  used  inside  since  it  is  used 

! to  denote  the  end  of  the  statement.  Any  number  of  DESCRIPTION 

I statements  may  be  given  for  an  object,  but  all  are  combined  into 

one  DESCRIPTION.  Any  subsequent  DESCRIPTIONS  are  concatenated 
[ to  the  current  DESCPIPTION. 

Syntax: 

DESCRIPTION  (DESC); 


(narrative  description) 

Example : 

To  describe  the  hiqhest  level  PROCESS  in  the  system  being 
described,  the  following  DESCRIPTION  statement  may  be 
applicable: 

DESCRIPTION; 

This  is  the  highest  level  process.  It  accepts  all  input  to  the 
system  and  produces  all  outputs.  ; 

3.2.3  KEYWORD  Statement 

The  KEYWORD  statement  can  be  used  to  logically  relate  object 
names  together  for  retrieval  and  subsequent  analysis  purposes. 
An  object  may  have  any  number  of  KEYWORDS. 
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Syntax: 

KRYWOPD  (KEY) 

(list  of  keyword  names) 


Fxa  irple: 

The  followinq  statement  may  be  used  to  identify  particular 
PROCESSES  as  lowest- level  processes: 

KEYWORD;  TERMINAL; 

All  PROCESSES  with  the  KEYWORD  "TERMINAL''  can  be  subsequently 
retrieved  together  and  analyzed  in  available  URA  reports. 

3.2.4  ATTRIBUTES  Statement 

ATTRIBUTES  are  used  to  state  specific  characteristics  of  given 
ob-Jects.  The  ATTRIBUTE  name  designates  the  name  of  the 
characteristic  and  the  ATTRIBUTE- VALUE,  the  value  or  magnitude 
of  this  characteristic.  The  ATTR IBOTE- VALUE  may  be  either  a URL 
name  or  an  integer. 

An  object  may  have  any  number  of  ATTRIBUTES.  A given  ATTRIBUTE 
can  refer  to  any  number  of  objects  not  necessarily  of  the  same 
type. 

Syntax: 

ATTRIBUTES  (ATTR)  , 

attribute  name  at  tribute- valu e name 


attribute  name  attribute- value  name 


attribute  name  attribute- value  name 


Example ; 

To  specify  that  a particular  data  element  is  numeric  field  of 
length  six,  the  following  statement  may  he  used: 

A"’TPIBUTES:  TYPE  NUMERIC, 

LENGTH  SIX  ; 


3.2.5  ASSERT  Statement 

The  ASSERT  statement  allows  the  Problem  Definer  to  assert  that 
one  object  must  have  a particular  ATTRIBUTE  and  ATTRIBUTE-VALUE 
when  related  to  another  object.  An  object  may  have  a number  of 
ASSERT  statements. 
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Syn  ♦•ax; 

ASSERT  (ASPT)  

(lis<:  of  naBPS  followed  by  attributes 
and  a t tribute-values) 


Example  ; 

If  PROCESS  qet-nane  DERIVES  name  USING  number,  an  appropriate 
ASSERT  Statement  would  be: 

ASSERT:  name  type  char, 

number  type  integer; 

3.2.f  PESPDNSIBLE-PROBLE M-DEPINEP  Statement 

The  RESPONSIBLE-PEOBLEM-DEFI NER  Statement  specifies  that  one 
problem  defin‘^>r  person  is  responsible  for  initial  preparation 
and/or  maintenance  of  an  object  description.  Only  one  problem 
definer  may  be  delegated  responsibility  for  a given  Section,  but 
mav  be  responsible  fcr  more  than  one  Section. 

Syntax: 

RESPONSIBILE-PROBLEE-DEFINER  (RPD)  ; 

(name  of  responsible- 
problem-  definer) 


Example: 

"^o  specify  that  “ichel  Bastarache  is  responsible  for  the  URL 
description  for  a narticular  object,  state; 

RESPON  SIPLF -PRO BLEW- DEFINER  MICHEL- BAST  APACHE; 

in  the  URL  Section  for  that  object. 

^•2.7  SEE- MEMO  Statement 

The  see-memo  statement  allows  a description  common  to  several 
objects  (and  available  in  a MEMO'S  DESCRIPTION)  to  be 
referenced.  '♦'his  statement  may  occur  any  number  of  times  for  a 
given  object. 

Syntax: 

SEE-M’PMO  (SM) ; 

(list  cf  memo  names) 


Example  ; 

To  refer  to  a particular  MEMO  on  programming  conventions 
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r^^lev^nt  tD  the  description  of  low  \evel  PROCESSES,  the 
follGwinq  may  cjiven; 

SEE-MTMO:  PBOGBAKMI NG-CCNVENTIONS; 

3.2.8  SOURCE  Statement 

The  SOURCE  statement  identifies  information  not  wiihin 

the  system  documentation  that  is  teto"*  ^ understanding 

of  the  system.  The  SOURCE  r.iy  be  a person,  a document  (such  as 
a practice  or  guideline),  at,:.  ^ny  number  of  SOURCES  lay  be 
c^'lated  to  an  obiect. 

Syn  tax: 

SOURCE  (SRC)  ; 

(list  of  source  names) 

Example: 

To  make  reference  to  a paper  written  by  Constantine: 

SOURCE:  CONSTANTIN?; 

"^he  URL  description  of  the  SOURCE,  name,  CONSTANTINE,  would 
probably  specify  relevant  information  such  as  name  of  paper, 
di*-p  published,  etc. 

3 . 2 . SECURITY  S ta t e me n t 

The  SECURITY  s^atpraent  specifies  the  level  of  security 
associated  with  a given  object's  URL  description.  Any  number  of 
SECURITIES  may  be  related  to  an  object. 

Syntax: 

SECURITY  (SEC)  ; 

(list  of  security  names) 


'=’xample : 

"o  specify  tha*-  the  URL  description  for  a given  object  may  only 
be  viewed  by  company  personnel,  the  following  statement  may  be 
used: 


SECURITY:  COMPANY; 

3.2.10  IRACE-KP Y St  a tement 

A '"RACE-KEY  is  used  to  correlate  objects  which  exist  in 
different  data-bases.  An  object  may  have  several  TRACE-KEYS. 
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Syntax; 

TRACE-KEY  (TKFY)  

(list  of  trace-key  names) 


Examole: 

security  level  in  a logical  system  design  data-base  and  a 
security  level  number  in  a physical  system  design  data-base  may 
both  have  the  statement; 

TRACE-KEY;  security-level-key; 


3.3  INTERFACE  Section 

PEA L-WOPLb- ENTI TIES  or  INTERFACES  are  named  objects,  outside  the 
target  system,  that  interact  with  the  system  being  described. 

If  the  system  being  described  was  a payroll  system,  one  possible 
INTERFACE  would  be  the  employees  paid  by  the  system.  They  could 
be,  in  one  sense,  t-he  customers  of  the  system. 

INTERFACE  (IN'^F) ; 

(list  of  interface  names) 

3.3.1  System-Flow  St  atements  for  INTERFACES 

The  RECEIVES  statement  is  used  to  specify  that  the  INTERFACE 
accepts  information  (OUTPUTS)  from  the  target  system. 

RECEIVES  (RCVS) ; 

(list  of  output  names) 

The  GENERATES  statement  is  used  to  specify  that  the  INTERFACE 
produces  information  (INPUT)  which  is  used  by  the  system. 

GENERATES  (GENS) ; 

(list  of  input  names) 

The  RESPONSIBLE  statement  specifies  that  an  INTERFACE  has  the 
responsibility  of  maintaining  information  (SETS)  within  the 
target  system. 

RESPONSIBLE  (RESP) ; 

(list  of  set  names) 

To  insure  completeness  of  the  problem  statement,  the  problem 
definer  should  check  that  every  INTERFACE  either  GENERATES  some 
INPUT,  RECEIVES  some  OUTPUT  or  is  RESPONSIBLE  for  some  SET. 

An  INTERFACE,  therefore,  can  interact  with  the  system  only 
through  RECEIVXNG  OUTPUTS,  GENERATING  INPUTS  or  being 
RESPCNSIBLE  FOR  SETS.  In  particular,  it  is  not  possible  to 


PART  I USER  REQUIREMENTS  LANGUAGE  MANUAL 


rBM3f 0/370/VS/TSO  ORL  OSEF’S  MANUAL 


132 


describe  any  processing  performed  in  the  INTERFACE.  If,  in  the 
system  description,  it  is  necessary  to  describe  processing  in 
the  INTERFACF,  then  it  should  be  designated  as  a PROCESS  instead 
of  an  INTERFACE.  See  section  4.1  on  system  boundaries. 


3.3.2  System-Struct  lire  Statements  for  INTERFACES 

An  IN^FRPACF  may  be  part  of  one,  and  only  one,  larger  INTERFACE, 
and  it  may  have  any  number  of  subparts  that  are  also  INTERFACES. 

PAR'^ ; 

(interface  name) 


SnRPAFTS  (SHBP) ; 

(list  of  interface  names) 

These  statements  permit  organization  structures  to  be  specified. 
This  can  be  used  to  obtain,  from  URA,  descriptions  of  the  system 
as  seen  from  a particular  part  of  the  organization. 


3.3.3  Data- Deri  vat  ion  Statements  for  INTERFACES 

In  the  target  system,  an  INTERFACE  may  have  the  right  to  access 
information  of  certain  classifications  and  categories. 

SEC  UEITY-ATCFSS-FISHT  (SAR) ; 

(list  of  classification  names 
optionally  followed  by 
classification  levels) 

3.3.4  Project- Management  statements  for  INTERFACES 

The  PFSPONSIRLE-PPOBLEM-DEFTNER  statement  may  he  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.2. 


3.3.5  System-Proper t ies  Statements  for  INTERFACES 

The  SYNONYMS,  OESCPIPTION,  SEE-MEMO,  KEYWORDS,  ATTRIBOTES, 
ASSERT,  SFCDRTTY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3. 2. 


3. 4 INPUT  Section 

INPUTS  are  information  that  is  produced  (GENERATED)  by 
INTERFACES  and  that  is  brought  into  (RECEIVED  BY)  the  target 
system . 
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INPUT  (TNP)  ; 

(list  of  input  names) 

T’hp  name  of  the  INPUT  can  be  considered  as  the  name  attached  to 
either  the  collection  of  data  values  or  the  physical  medium  on 
which  the  data  values  are  recorded,  i.e.,  the  carrier  of  the 
data  values,  or  to  both. 


3.4.1  System-Flow  S t atement  s for  INPUTS 

'’’he  names  of  the  INTERFACES  providing  the  INPUT  are  given  in  the 
(1FNFFATED  statement. 

GEWERATED  BY  (GEND) ; 

(list  of  interface  names) 

The  object  in  the  system  which  accepts  the  INPUT  is  given  in  the 
RECEIVED  BY  statement; 

RECEIVED  BY  (PCVP) ; 

(list  of  process  names) 

’’’hese  statements  refer  only  to  the  logical  collection  of  data 
elements  value,  and  provide  a way  of  stating  where  the  INPUT 
comes  from  and  what  PROCESS  must  accomplish  whatever  is 
necessary  to  "accept"  it.  All  operations  on  the  data  element 
values  must  be  specified  separately  in  the  definition  of  the 
PROCESS. 

Every  INPUT  should  be  GENERATED  by  at  least  one  INTERFACE  and 
RECEIVED  bv  at  least  one  PROCESS. 


3.4.2  Sistemrft  r uc t u re  Statements  for  INPUTS 

An  INPUT  may  be  part  of  one,  and  only  one,  larger  INPUT,  and  it 
may  have  any  number  cf  subparts  that  are  also  INPUTS. 

PAR"' : 

(name  of  input) 

SUBPARTS  (SUBP)  ; 

(list  of  input  names) 

'’’hese  statements  allow  definitional  structures  (grouping  INPUTS 
together  to  call  them  by  a single  name)  and  high  level  data 
structures  to  be  specified.  The  lowest  level  of  INPUTS  normally 
will  he  used  for  physical  documents,  messages,  cards,  etc.,  that 
flow  into  the  system. 

■"o  describe  a collection  of  INPUT  occurrences  (SET  of  INPUTS), 
the  CONTAINED  statement  may  be  used  to  relate  INPUTS  to  SETS. 
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COV'^*IfJBD  (CV'"D) ; 

(list  of  set  names) 

■^his  SET  can  then  he  used  in  further  statement  of  requirements. 
This  might  be  used,  for  example,  to  describe  a batch  of  inputs 
such  as  time  cards  which  are  to  be  treated  as  a unit  for 
nrocessinq. 

»n  INPtiT  can  be  contained  in  any  number  of  SETS. 


3.4.3  Data- Stru ctur e Statements  for  INPUTS 

The  data  (GPO'JPS  and  ELEMENTS)  whose  values  appear  on  an  INPUT 
are  defined  via  the  CONSISTS  statement.  Each  data  name  used  in 
the  statement  can  he  optionally  preceded  by  a SYSTER-PA aABETEE 
to  define  the  number  of  occurrences  of  the  data  value  that  may 
appear  on  the  INPJtT.  The  CONSISTS  statement  only  specifies  tha 
data  on  the  INPUT  and  implies  nothing  about  format. 

CONSTS'^S  (CSTS) ; 

(list  of  group  and  element 

each  name  optionally 

presented  by  a system- parameter . ) 

A complete  nrohlem  statement  should  hav»  all  INPUTS  (which  do 
not  have  SUBPAFTS  statements)  broVen  down  into  GROUPS  and 
ELEMENTS. 


3.4,4  Pata^Deri  vat  i on  Statement  X2I  IN  POTS 

""ho  USED  statements  specifies  those  PROCESSES  which  use  the 
information  available  in  the  INPUT. 

US^’D ; 

(list  of  process  names) 

"^his  implies  that  at  least  one  piece  of  data  (GROUP  or  ELEMENT) 
on  the  INPUT  is  being  USED,  To  specify  the  manner  in  which  the 
INPUT  is  used  more  precisely,  the  DERIVE  or  UPDATE  clause  may  be 
used  ir  conjunction  with  the  USED  statement. 

USSr  BY  

(list  of  process  names) 

TO  DERIVE  (DRV) ; 

(list  of  element,  group,  entity, 
sp^  and  output  names) 


USED  BY 

(list  of  process  names) 

•"0  UPDATP  (UPD)  
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(list  of  element,  qroup, 
entity  and  set  names) 

An  INPUT  may  be  USED  by  any  number  of  PROCESSES.  Every  INPUT 
should  be  used  by  at  least  one  PROCESS. 

The  CLASSIFICATION  of  an  INPUT  may  be  specified  with  the 
CLASSIFICATION  statment; 

CLASSIFICATION ; 

(list  of  classfication  names, 
each  optionally  followed  by 
a level  number) 

Anv  PROCESSES  or  PROCESSORS  that  use  the  INPUT  must  have 
SFC UPITY-ACCESS-RISHTS  that  match  the  classification  of  the 
INPUT. 


3.4.5  System-Dynamics  Statements  for  IN  PUTS 

More  than  one  individual  instance  of  an  INPUT  may  occur  over 
some  period  of  time.  The  number  of  instances  of  the  INPUT  that 
occur  over  time  is  stated  through  the  HAPPENS  IIMES-PER 
statement: 

HAPPENS  (HAP) 

(system -par  a meter) 

TTMES-PER  (TIHP) ; 

(interval  name) 

Every  INPUT  should  have  a HAPPENS  statement.  An  INPUT  can  have 
only  one  HAPPENS  statement. 

The  arrival  of  an  INPUT  may  affect  the  processing  currently 
being  performed,  or  it  may  initiate  new  processing.  This  is 
described  via  the  TRIGGERS,  TERMINATES  and  INTERRUPTS 
statements ; 

TRIGGERS  (TRGS) ; 

(list  of  process  names) 

TERMINATES  (TRMS) ; 

(list  of  process  names) 

INTERRUPTS  (INTS) ; 

(list  of  process  names) 

The  arrival  of  an  INPUT  may  also  cause  an  EVENT  or  set  the  value 
of  a CONDITION. 

CAUSES  (CSS) ; 

(list  of  event  names) 


i 


I 

I 
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■'AKES  (WAK) TRUE  (T)  ; 

(list  of  condition  names) 

MAKES  («AK) FALSE  (F)  ; 

(list  of  condition  names) 

An  INPUT  mav  or  may  not  he  involved  in  any  system  dynamics 
relationships. 

3.4.6  Project-Management  St ateaents  for  INPOT 

The  PESPONSIBLE-PPOPLEM-DE’'INEF  Statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.2 


3,4.7  System- Proper t ies  Statements  for  INPUTS 

The  SYNONYMS,  DESCRIPTION,  SHE-HEKO,  KEYWORDS,  ATTRIBUTES, 
ASSEPT,  SECURITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3. 2. 

3 . S OUTPUT  Section 

OUTPUTS  are  information  that  is  produced  (GENERATED)  by  the 
target  system  (PROCESSES  within  the  system)  and  that  goes  to 
(are  RECEIVED  BY)  INTERFACES. 

OUTPUT  (OUT) ; 

(list  of  output  names) 

The  name  of  the  OUTPUT  can  be  considered  as  the  name  attached  to 
either  or  the  collection  of  data  values  or  the  physical  medium 
on  which  the  data  values  are  recorded,  i.e. , the  carrier  of  the 
data  values  or  to  both. 


l.S.I  System-Flow  St^ements  for  OUTPUTS 

The  names  of  the  PROCESSES  producing  the  OUTPUT  are  given  in  the 
GBNFPA'^ED  statement. 

GENERATED  BY  (GEND) ; 

(list  of  process  names) 

■rhp  INTERFACES  which  accept  the  OUTPUT  are  given  in  the  RECEIVED 
BY  statement: 

RECEIVED  BY  (PC  VD) ; 

(list  of  interface  names) 
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"^hese  statements  refer  only  to  the  logical  collection  of  data 
elements  values,  and  provide  a way  of  stating  vhat  PROCESSES 
must  produce  the  OUTPUT  and  where  it  must  be  transmitted  to. 
All  operations  on  the  data  element  values  must  be  specified 
senarately  in  the  definition  of  the  PROCESS. 

Every  OUTPUT  should  be  GENERATED  by  at  least  one  PROCESS  and 
RECEIVED  by  at  least  one  INTERFACE. 


3.5.2  System- St  ruct  ure  Statements  for  OUTPUTS 

An  OUTPUT  may  be  part  of  one,  and  only  one,  larger  OUTPUT,  and 
it  may  have  any  number  of  subparts  that  are  also  OUTPUTS. 


PART 


(name  of  output) 


SUBPARTS  (SUBP) 


(list  of  output  names) 


These  statements  allow  definitional  structures  (grouping  OUTPUTS 
together  to  call  them  a single  name)  and  high  level  data 
structures  to  he  specified.  The  lowest  level  of  OUTPUTS 
normally  will  be  used  for  physical  documents,  messages,  cards, 
etc.,  that  flow  out  of  the  system. 

■^o  describe  a collection  of  OUTPUT  occurrences  (SETS  of  OUTPUTS) 
the  CONTAINED  statement  may  be  used  to  relate  OUTPUTS  to  SETS. 


CONTAINED  (CNTD) 


(list  of  set  names) 


■"his  SET  can  then  be  used  in  further  statement  of  requirements, 
’’’his  might  be  used,  for  example,  to  describe  a batch  of  outputs 
that  are  to  be  produced  as  a unit. 

An  OUTPUT  can  be  contained  in  any  number  of  SETS. 

3.5.3  Data-Structure  Sta temen ts  for  OUTPUTS 

The  data  (GROUPS  and  ELEMENTS)  whose  values  appear  on  an  OUTPUT 
are  defined  via  the  CONSISTS  statement.  Each  data  name  used  in 
the  statement  can  be  optionally  preceded  by  a SYSTEM-PARAMETER 
to  define  the  number  of  occurrences  of  the  data  value  that  may 
appear  on  the  OUTPUT.  The  CONSISTS  statement  only  specifies  the 
data  on  the  OUTPUT  and  implies  nothing  about  format. 


CONSISTS 


(CSTS) 

(list  of  group  and  element  names, 
each  name  optionally  preceded  by 
a system  parameter) 
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1 

A complete  problem  should  have  all  OUTPUTS  that  do  not  have  | 

SOBPAPTS  statements  broken  down  to  GROUPS  and  ELEMENTS.  | 

! 

The  CLASSIFICATION  of  an  OUTPUT  may  be  specified  with  the  i 

CLASSTFICA'^ION  statment: 

CLA SSTFICATIOV ; j 

(list  of  classification  names,  each 
optionally  followed  by  a level  number) 

Any  PROCESSES  or  PROCESSORS  that  use  the  OUTPUT  must  have 
SECUPTTY-ACCESS-PIGHTS  that  match  the  classification  of  the 
OUTPUT. 


3.5.4  Data- Derivation  Statements  for  OUTPUTS 

The  DERIVED  statement  specifies  those  PROCESSES  that  derive  some 
information  presented  on  the  OUTPUT. 

DERIVED  (DRVD) ; 

(list  of  process  names) 

"^his  statement  implies  that  at  least  one  piece  of  data  (GROUP  or 
ELEMENT)  on  the  OUTPUT  is  DERIVED. 

To  specify  more  precisely  how  the  OUTPUT  is  derived,  the  USING 
clause  may  be  used  in  con-junction  with  the  DERIVED  statement. 

DERIVED  BY  (DPVD) 

(list  of  process  names) 

USING ; 

(list  of  input,  set,  entity,  group 
and  element  names) 


3.5.5  System-Dy namics  Statements  for  OUTPUTS 


More  than  one  individual  instance  of  an  OUTPUT  may  occur  over 
some  period  of  time.  The  number  of  instances  of  the  OUTPUT  that 
occur  over  time  is  stated  through  the  H APPENS/TI MBS  PEP 
statement: 

HAPPENS  (UAP) 

( sys  tem-pa  rame  te  r) 

"TMES-PER  (TIMP)  ; 

(interval  name) 


Every  OUTPUT  should  have  a HAPPENS/TIMES  statement, 
can  have  only  one  HAPPENS  statement. 


An  OUTPUT 
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3.5,6  Pcolect-Managenent  Statements  for  OUTPUTS 

The  RESPONSTSLFl-PROBLEM-DEPINER  statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.2. 


3.5.7  System- Property  Statements  ^or  OUTPUTS 

The  SYNONYMS,  DESCRIPTION,  SEE-MEMO,  KEYWORDS,  ATTRIBUTES, 
ASSERT,  SECURITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3.  2. 


3.6  ENTITY  Sect  ion 

An  ENTITY  is  a collection  of  information  manipulated  {USED, 
DERIVED  and  UPDATED)  by  the  target  system.  An  ENTITY  differs 
from  an  INPUT  or  OUTPUT  in  that  it  is  information  maintained 
entirely  internal  to  the  system  and  can  never  cross  the  system 
boundaries  (i.e.,  be  GENERATED  or  RECEIVED). 

INPUTS,  OUTPUTS  and  ENTITIES  are  similar  constructs,  though  only 
ENTITIES  can  be  logically  connected  through  RELATIONS. 

ENTITY  (ENT) ; 

(list  of  entity  names) 

In  many  applications  the  usage  of  ENTITIES  is  synonymous  with 
logical  records.  For  example,  if  an  employee  payroll  processing 
system  were  being  designed,  the  information  needed  about 
salaried  and  hourly  employees  might  be  stored  on  records  which 
would  be  defined  as  ENTITIES. 


3,6.1  System  Structure 

To  describe  a collection  of  ENTITY  occurrences  (sometimes  also 
called  a file)  the  CONTAINED  statement  may  be  used  to  relate 
ENTITIES  to  SETS. 


CONTAINED  (DNTD) 


(list  of  set  names) 

This  SET  can  then  be  used  in  further  statement  of  requirements. 
This  might  be  used,  for  example,  to  describe  a file  of  employee 
records  which  are  to  he  treated  as  a unit  for  processing. 


3.6.2  Data- Structur  e Statement^  for  ENTITIES 

The  data  (GROUPS  and  ELEMENTS)  whose  values  appear  in  an  ENTITY 
are  defined  via  the  CONSISTS  statement.  Each  data  name  used  in 
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the  statement  can  be  optionally  preceded  by  a SYSTEM-PARAMETER 
to  define  the  number  of  occurrences  of  the  data  value  that  may 
appear  on  the  ENTITY. 

The  CONSISTS  statement  only  specifies  the  data  on  the  ENTITY  and 
implies  nothing  about  its  format. 

CONSISTS  (CSTS)  ; 

(list  of  qroup  and  element  names,  each  name 
optionally  preceded  by  a system  parameter) 

A complete  problem  statement  should  have  all  ENTITIES  broken 
down  to  CROUPS  and  ELEMENTS. 

To  specify  that  each  ENTITY  occurrence  may  be  uniquely 
identified  by  one  or  more  keys,  the  IDENTIFIED  statement  is 
used. 

IDENTIFIED  (TDD)  ; 

(list  of  qroup  and  element  names) 

The  RELATED  statement  specifies  a logical  connection  between  two 
ENTITIES. 


PEI.ATED  (REL) 


VIA 


(name  of  entity) 
(name  of  relation) 


This  implies  that  given  one  of  the  two  ENTITIES,  information 
from  the  other  can  be  found. 


3.f.3  Data- Peri vat  ion  St  atements  for  ENTITIES 

The  USED  statement  specifies  those  PROCESSES  which  use  the 
information  available  in  the  ENTITY. 

USED ; 

(list  of  process  names) 

This  statement  implies  that  at  least  one  piece  of  data  (GROUP  or 
EL'='HENT)  in  the  ENTITY  is  being  USED. 

To  specify  the  manner  in  which  the  ENTITY  is  USED  more 
precisely,  the  DERIVE  or  UPDATE  clause  may  be  used  in 
conlunction  with  the  USED  statment. 

USEE  EY  

(list  of  process  names) 

TO  DERIVE  (DRV) ; 

(list  of  element,  group,  entity 


PART  I USER  REQUIREMENTS  LANGUAGE  MANUAL 


TP*n6C/370/VS/TSO  URL  USER'S  MANUAL  141 


set  and  output  naaes) 
or  USED  by  a PROCESS  to  UPDATE  data; 

USED  BY 

(list  of  process  nanes) 

! TO  UPDATE  (UPD) ; 

I (list  of  element,  group, 

* entity  and  set  names) 

I The  DERIVED  statemant  specifies  those  PROCESSES  vhich  derive 

i some  information  presented  in  the  ENTITY. 

‘ DERIVED  (DRVD) ; 

I (list  of  process  names) 

t This  statement  implies  that  at  least  one  piece  of  data  (OROUP  or 

ELEMENT)  in  th«  EN'^TTY  is  DERIVED.  To  specify  the  manner  in 
I which  the  ENTITY  is  derived  more  precisely,  the  USING  clause  may 

j he  used  in  coniunction  with  the  DERIVED  statement. 

I DERIVED  BY  (DRVD) 

(list  of  process  names) 

f 

USING ; 

(list  of  element,  group,  entity, 
set  and  input  names) 

The  UPDATED  statement  specifies  those  PROCESSES  that  modified 
some  information  presented  in  the  ENTITY. 

UPDATED  (UPDD) ; 

(list  of  process  names) 

This  statement  implies  that  at  least  one  piece  of  data  (GROUP  or 
ELEMENT)  in  the  EN'^ITY  is  UPDATED. 

'^'o  specify  more  precisely  the  manner  in  which  the  ENTITY  is 
undated,  the  USING  clause  may  be  used  in  conjunction  with  the 
UPDATED  statement. 

UPDATED  BY  (UPDD) 

(list  of  process  names) 

USING ; 

(list  of  element,  group,  entity, 
set  or  input  names) 

Every  ENTITY  defined  should  he  USED,  DERIVED  or  UPDATED  by  at 
least  one  PROCESS. 

The  CLASSIFICATION  of  an  ENTITY  may  be  specified  with  the 
CLASSIFICATION  statement: 


J 


PART 


USER  REQUIREMENTS  LANGUAGE  MANUAL 


IBH3fO/370/VS/TSO  DPL  USER'S  MANUAL 


m2 


CLASSIFICATION ; 

(list  of  classification  names,  each 
optionally  followed  by  a level  niimber> 

Any  PPOCBSSEF  or  PROCESSORS  that  use  the  ENTITY  must  have 
SSCURTTY-ACCESS-RTOHTS  that  match  the  classification  of  the  , 
ENTITY. 


3 . . U System-Size  S t ateaen  t s for  ENTITI  ES 

The  cardinality  statement  specifies  the  maximuni  number  of 
occurrences  of  a particular  ENTITY  in  the  target  system  at  any 
time . 


CARDINALITY  (CARD) 


(system  parameter) 


Every  ENTITY  should  have  a CARDINALITY. 


3.6.5  System-Dynamics  Statements  for  EN TITI ES 

The  VOLATILI'T’Y  statement  specifies  the  manner  in  which  an  ENTITY 
changes  over  time.  Since  there  are  many  different  ways  in  which 
an  ENTITY  may  be  changed,  this  information  is  entered  via  a 
comment  entry.  The  type  of  information  specified  in  this 
statement  might  be  the  number  of  times  a particular  ENTITY 
occurrence  would  bo  updated  in  a given  time  interval,  how  often 
ENTITY  occurrences  would  be  deleted,  and  often  created,  etc. 

VOLATILITY  (VOL) ; 


(comment  entry) 

Every  ENTITY  should  have  a VOLATILITY. 


3.6.6  P ro dec t- Management  Statements  for  ENTITIES 

■^he  RES  PON  ST  BLE- PRO  B LE.M-DE'' IMEF  statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.2. 

3.6.7  Svstem-Propert ies  Statements  for  ENTITIES 

'"he  SYNONYMS,  DESCRIPTION,  SEE-MEMO,  KEYWORDS,  ATTRIBUTES, 
ASSERT,  SECURITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3. 2. 
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3.7  SET  Sect  ion 

A SET  is  a collection  of  one  or  mere  ocurrences  of  objects  that 
contain  or  carry  dat.^  values.  A SET  nay  represent  a collection 
of  ENTITIES,  INPUTS,  or  OUTPUTS,  but  not  a combination  of  these 
obiect  types.  That  is,  a SET  cannot  consist  of  both  INPUTS  and 
OUTPUTS. 

SET ; 

(list  of  set  names) 

Where  ENTITIES  may  he  thought  of  as  logical  records,  a SET  may 
he  thought  of  as  a logical  file.  In  any  case,  a SET  should  be 
used  according  to  the  algebraic  sense  of  the  word  "set." 

3.7.1  System-Fl  ow  -T^^ements  fo£  SETS 

The  RESPONSIBLE-INTERFACE  Statement  specifies  those  INTERFACES 
that  have  the  responsibility  of  maintaining  the  information  in 
the  SET. 

RESFONSTBLE-IN" EFFACE  (PINT) ; 

(list  of  interface  names) 

Every  S E™  should  have  at  least  one  responsible  INTERFACE. 


3. 1. 2 System-S^  met  ure  S ta  t omen  ts  for  5 ETS 

The  SUBSETS  and  SUBSE'^  statements  specify  the  manner  in  which  a 
particular  SE"^  is  related  (in  the  algebraic  sense,  again)  to 
other  SETB  in  the  target  system. 

A SE’’"  can  be  a SUBSET  of  a larger  (or  equivalent  size)  SET: 

SUBSET  (SST)  ; 

(list  of  set  names) 

A.  SET  can  also  have  a number  of  SUBSETS: 

SUBSETS  (SSTS) ; 

(list  of  set  names) 

For  example,  a lata-base  may  be  defined  to  describe  all  the 
information  maintained  by  thvO  target  system.  The  data-base  may 
be  defined  to  be  a SET.  Smaller  collections  of  data  in  the 
data-base  such  as  files,  etc,,  would  then  be  defined  as  SUBSETS 
of  the  data-base. 

The  SUB  SETTING- CPIT ERIA  Statement  specifies  what  data  determines 
how  a SET  is  to  be  subsetted. 

SUB  SETTING-CRITERIA  (SSCA)  ; 
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(list  of  subsetting-criterion, 
element,  and  group  names) 

If  a SFT  has  SUBSETS,  its  SDBSETTING-CRITEPI A should  be  defined 
also . 


3.7.3  Data-  Structure  Statements  f or  SETS 

The  CONSIS'^S  statement  specifies  the  data  contained  in  the  SET 
and,  optionally,  the  number  of  occurrences  of  this  data  in  the 
SET. 

CONSISTS  (CSTS) ; 

(list  of  entity,  input  or 
output  names,  optionally 
preceded  by  system- 
pa  rameters) 

Every  SET  should  CONSIST  of  at  least  one  ENTITY,  INPUT,  or 
OUT  PUT. 


’.7.4  Data -Derivation  Statements  SETS 

The  USED  statement  specifies  those  PROCESSES  which  use  the 
information  available  in  the  SET. 

USED ; 

(list  of  process  names) 

'T’his  implies  that  some  data  within  the  SET  is  being  USED. 

"^o  specify  the  manner  in  which  the  SET  is  USED  more  precisely, 
the  DERIVE  or  UPDATE  clause  may  be  in  coniunction  with  the  USED 
statement. 

USED  BY  

(list  of  process  names) 

TC  DERIVE  (DRV) ; 

(list  of  element,  group,  entity, 
set  and  output  names) 

or  USED  by  a PROCESS  to  UPDATE  data; 

USED  BY 

(list  of  process  names) 

TO  UPDATE  (UPD) ; 

(list  of  element,  group,  entity, 
and  set  names) 

"he  DERIVED  stitement  specifies  those  PROCESSES  which  derived 
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some  information  presented  in  the  SET. 

DERIVED  (DPVD) ; 

(list  of  process  names) 

This  statement  implies  that  at  least  one  piece  of  data  (ENTITY 
or  OUTPUT)  in  the  SET  is  DERIVED.  To  specify  ♦’he  manner  in 
which  the  ENTITY  or  OUTPUT  is  derived  more  precisely,  the  U5IN3 
danse  may  be  used  in  con-iunction  with  the  DERIVED  statement. 

DERIVED  BY  (D”Vn) 

(list  of  process  names) 

USING ; 

(list  of  element,  qroup,  entity, 
set  and  input  names) 

The  UPDATED  stitement  specifies  those  PROCESSES  that  may  modify 
information  in  the  SET. 

UPDATED  (UPDO)  ; 

(list  of  process  names) 

This  statement  implies  that  at  least  one  piece  of  data  (ENTITY) 
in  the  SET  is  UPDATED. 

To  specify  more  precisely  the  manner  in  which  the  SET  is 
undated,  the  using  clause  may  be  used  in  conjunction  with  the 
UPDATED  statemp>nt. 

updated  BV  (UPDD) 

(list  of  process  names) 

U SING ; 

(list  of  elemen*- , group,  entity, 
se*;  or  i n put  names) 

’^very  SET  defined  should  be  USED,  DERIVED  or  tjPDATSD  by  at  least 
one  FPCCESS. 

The  DERIVATION  statement  should  be  used  to  specify  the  rules  for 
deriving  occurrences  of  data  in  the  SET.  Since  there  are  many 
different  wavs  in  which  this  data  may  be  derived,  this 
information  is  pr-^sented  via  a comment  entry.  The  type  of 
information  specified  in  this  statemnt  might  be  what  value  a 
particular  ELEMENT  in  an  ENTITY  must  have  to  he  entered  into  a 
SET,  etc. 

DHR  IVA^'ION  (DRV  N)  ; 


(comment  entry) 

Every  SET  should  have  DERIVATION  specified. 
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The  CLASSIFICATION  of  a SFT  raay  be  specified  with  the 
CLASSIFICATION  statenent: 

CLASSIFICAT'ION ; 

(list  of  classification  names, 
each  optionally  followed  by 
a level  number) 

Any  FFOCESSFS  or  PPOCFSSORS  that  use  the  SET  must  have  SECUPITif- 
ACC  ESS- RIGHTS  that  match  the  classification  of  the  SET. 


3.7.f  System-Si ze  S tatement  s for  SETS 

The  CARDINALITY  statement  specifies  the  maximum  number  of 
occurrences  of  data  objects  in  the  SET  at  any  one  time. 

CARDINALITY  (CARD) ; 

(system  parameter) 

Every  SET  should  have  a CARDINALITY. 


3 , 7 . ft  System- Dynamics  Statements  SETS 

The  VOLATILITY- SET  and  VOLATILITY-MEMBER  statements  specify  how 
a SFT  chanqes  over  time.  Since  there  are  many  different  ways  in 
which  a SET  may  be  changed,  this  information  is  presented  via  a 
comment  entry. 

"^he  VOLATILITY- SET  statement  specifies  the  manner  in  which  the 
“n^ ire  set  changes  over  time.  The  type  of  information  specified 
in  this  statement  might  be  the  number  of  times  members  are  added 
to  the  SET,  members  are  updated,  etc. 

VOLATILITY- SET  (VOLS); 


(comment  entry) 

The  VOLATILI TY- MEK9 FR  statement  specifies  how  the  members  of  the 
SE^  change  over  time.  The  type  of  information  specified  in  this 
statement  might  he  the  number  of  additions  to  the  SET  of  a 
particular  EN'^TTY  type,  the  number  deleted,  etc. 

VOLATILITY- MEMBER  ( VOLH)  ; 


(comment  entry) 

Every  SET  should  have  VOLATILITY-SET  and  VO LATI LITY- HEM  BE R 
statements  given  for  them. 
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3.7.7  P r oj  e c t- M ana  c;e  went  St  atemen  ts  for  SETS 

ThP  RESPONSIBLE-PPOBLFM-DEFINEB  statosent  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  qiven  in 
section  3.  2 . 

3.7.P  S yst em-Proper t ies  Stat  ement  g for  SETS 

The  SYNONYMS,  DESCRIPTION,  SEE-MEEO,  KEYWORDS,  ATTRIBUTES, 
ASSERT,  SECUPIty,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3.2. 


3.3  RELATION  Eec^ion 

A FElA'^'rON  is  a named  logical  connection  between  two  ENTITIES 
perceived  by  the  Problem  Definer.  Any  URL  name  may  be  used;  the 
most  meaningful  name  to  the  Problem  Definer  should  be  one  which 
denotes  the  connected  ENTITIES. 

PELATION  ; 

(list  of  relation  names) 

If  a system  were  being  described  that  consisted  of  ENTITIES  for 
women  and  ENTITIES  for  men,  a possible  RELATION  to  connect  these 
ENTITIES  might  be  "spouse.” 


3.3.1  D a ta-  S true''  ure  Statements  for  RELATIONS 

A BETWEEN  statement  specifies  the  names  of  the  ENTITIES  that  the 
RELATION  connects  and  the  direction  of  the  connection.  The 
direction  is  determined  by  the  order  of  the  ENTITY  names  in  the 
statement;  from  the  left  (first)  ENTITY  to  the  right  (second) 
ENTITY.  The  firs'-  ENTITY  can  be  considered  the  owner  of  the 
PELATION  and  '■he  second  ENTITY  the  member  of  the  RELATION. 

B ET  W^EN 


AND 


Pxa  mple ; 

The  PFLAnON,  D E PAP  TMENT-TO-BC  URL  Y- EMPLOYES , denotes  a logical 
connection  between  two  ENTITIES,  DEPARTMENT- RECORD  and 
HOURLY-SMOLOYEE-RFCORD.  The  direction  is  from  DEPARTMENT-RECORD 
to  HCnPLY-FMPLOYEF-FECOPD.  The  DEP  AR  TM  ENT- R ECOR  D is  the  owner 
and  HOURLY-EMPLOYMENT-PECORD  the  member  of  the  RELATION. 

Only  one  BETWEEN  sf atement  can  be  given  for  a particular 


(name  of  entity) 

Iname  of  entity) 

BETWEEN  DEPARTMENT-RECORD  AND  HOURLY-EM PLOY EE- RECORD : 
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RELATION,  but  pach  PELATION  should  have  a BETWEEN  statement 
qiven  for  it. 

The  ASSOCIAT ED- DATA  statement  specifies  those  GROUPS  and 
ELEMENTS  that  contain  information  specifically  about  the 
RELATION  and  are  not  necessarily  CONTAINED  in  either  ENTITY. 

ASSOCIATED-DATA  IS ; 

(list  of  element  and  group  names) 

3.8.2  Data- Derivation  Statements  for  RE  LATIONS 

A MAINTAINED  BY  statement  designates  those  PROCESSES  which  add, 
delete  or  modify  the  connection  occurrences  between  the  ENTITIES 
that  are  connected  by  this  RELATION. 

MAINTAINED  BY ; 

(list  of  process  names) 

A RELATION  can  be  MAINTAINED  by  several  PROCESSES,  and  every 
PELATION  should  be  MAINTAINED  by  at  least  one  PROCESS. 

The  DERIVATION  statement  should  be  used  to  specify  the  rules  for 
deriving  occurrences  of  the  RELATION  between  the  ENTITIES  . 

Since  there  are  many  different  ways  in  which  this  data  may  be 
derived,  this  information  is  presented  via  a comment  entry.  The 
type  of  information  specified  in  this  statement  might  be  what 
are  the  restrictions  in  relating  two  ENTITIES,  which  PROCESSES 
may  forma  the  relation,  etc. 

DERIVATION  (DRVN); 


(comment  entry) 

Every  PELATION  should  have  a DERIVATION  specified. 


3.8.3  System- Size  Statement  s for  REIATI ONS 

A CONNECTIVITY  statement  specifies  the  number  of  ENTITY 
occurrences  of  the  first  (right)  ENTITY  that  are  related  to  a 
number  of  ENTITY  occurrences  of  the  second  (left)  ENTITY. 

CONNECTIVITY  IS  

(system- par  a meter) 

TO ; 

(system-  parameter) 

If  a particular  ENTITY  occurrence  may  be  related  to  only  one 
other  ENTITY  occurrence,  the  CONNECTIVITY  is  1 to  1.  If  a 
particular  ENTITY  occurrence  may  be  related  to  one  or  more 
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P^«riTY  occurrences  the  CONNECTIVITY  is  one  to  many.  The  right 
and  left  SY  STEM -^A'’ AMETEES  in  the  CONNECTIVITY  are  intended  to 
correspond  to  ‘■he  right  and  left  ENTITIES  given  in  the  3HTMEEN 
statement. 

Every  RELATION  should  have  one,  and  only  one,  CO  NNECTIV  IT  Y. 

A CARDINALITY  statement  specifies  the  maximuai  number  of 
connection  occurrences  for  this  RELATION. 

CARDINALITY  IS ; 

(sys  tern- para  meter) 

Every  RELATION  should  have  one,  and  only  one,  CARDINALITY. 


3 . P . 4 Project- Management  Statemen  ts  for  RELATIONS 

The  RES ooN SI  RLE  - PROP LFM-DEF INE B Statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  stateant  is  given  in 
section  3.2. 


3.3.5  S ystem- Proper  t jes  Stat  ement  s for  RELATIONS 

The  SYNONYMS,  DESCRIPTION,  SEE-MEMO,  KEYWORDS,  ATTRIBUTES, 
ASSERT,  SECUPT'^Y,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  section.  Description  and  syntax  of  these  statements  are 
ciiven  in  section  3.2. 


3.3.6  Example  of  a Complete  REIATICN  Section 

RELATION  depar*-  ment-  to-h our ly -employee; 

ASSOCIATED-DATA  is  last-department-change; 

ATTRIBUTE  IS  f r equency - o f- use;  high; 

BETWEEN  d-i  par t ment- rec ord  AND  hourly-eraployee-record  ; 
CARDINALITY  IS  num ber- o f- hou r ly-em ploy ees; 

CONNECTIVITY  IS  1 TO  max-de  ar  tmen  t-em  ployemen  t ; 
DERIVA'"ION  ; 

new-emoloyee-processing  adds  connections  while 
term ina ting-employee- processing  deletes  connections; 
DESCRIPTION; 

this  relation  connects  an  hourly-employee-record  for 
each  employee  in  a department  to  the  department-record 
for  that  department; 

KEYWORD  department-information; 

MAINTAINED  BY  n ew-e mployee- process inq  AND 
term ina tinq-employec-processinq  /♦  USING 
department  AND  employee- identif  ication-number  */; 
PESPONSIBLE-PF  OPLEM-DEFINER  john-proctor ; 

SECURTY  department-heads,  department-secretaries; 

SER-MEKO  company-orqani'zation-char  t; 


PART  I USER  REQUIREMENTS  LANGUAGE  MANUAL 


IPK360/370/VS/TSO  ORL  USER'S  MANUAL 


150 


SOURCE  e «ployee-appl i cat ion- form , 

p mplo veG-term ina  t ion-form , 
lepar  tment-enployee-list; 
SYNONYM  dapt-to-emp,  d-e; 


3.9  GROUP  and  ELEMENT  Sections 

An  ELEMENT  is  the  lowest  level  data  ob-ject  that  can  be  defined 
*-o  describe  data.  Pecause  of  this  property,  an  ELEMENT  has  one 
or  more  possibl®  data  values  associated  with  it,  whether  it  be 
alphabetic,  numeric  or  otherwise.  In  many  instances  an  ELEMENT 
may  be  thought  of  synonymously  with  "field"  or  "item." 

ELEMEN"'  (ELE) ; 

(list  of  element  names) 

A GROUP  represents  a collection  of  ELEMENTS  and/or  GROUPS.  The 
use  of  GROUPS  is  definitional  which  means  that  referencing  a 
particular  GROUP  by  its  name  is  equivalent  to  referencing  the 
individual  ELEMENTS  which  the  GROUP  consists  of. 

GROUP  (GR) ; 

(list  of  group  names) 

GROUPS  can  be  broken  down  into  smaller  GROUPS  and  ELEMENTS,  but 
ELEMENTS  cannot  be  subdivided.  ELEMENTS  may  take  on  values 
where  GROUPS  may  not.  The  value  of  a GROUP  is  defined  to  be 
equivalent  to  the  individual  values  of  the  ELEMENTS  within  the 
GROUP. 


3.9.1  S^ste  mj;Structure  Statements  for  GROUPS  and  ELEMEN TS 

The  SUB  SETT  NG-C  RITE  P TON  statement  specifies  those  SETS  which  are 
subsetted  based  on  the  data  values  in  the  GROUP  or  ELEMENT. 

SUPSETTING-CPIT  ERION  (SSCN)  ; 

(list  of  set  names) 


3.9.2  Data-Structur  e St  atem entg  for  GRO  UPS  and  ELEMENTS 

'^he  CONTAINED  statement  is  used  to  relate  the  data  structure 
relationships  of  GROUPS  and  ELEMENTS  to  ENTITIES,  INPUTS  and 
OUTPUTS.  Data  is  most  often  thought  to  be  part  of  some  large 
unit  of  data  such  as  a logical  record,  input  form,  or  output 
report,  which  can  be  represented  by  the  ENTITY,  INPUT  and 
OUTPUT,  respectively. 

CONTAINED  (CN'^’D) ; 

(list  of  group,  entity, 
input  and  output  names) 
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'IROUPS  anfl  ELEMENTS  nay  be  defined  to  be  CONTAINED  in  somo 
larger  CROUP. 

The  CONSISTS  ntateinent  is  used  to  specify  those  lower  level 
CROUPS  and  ELEMENTS  a CFOUP  may  consist  of.  Dy  definition  of 
"ELEMENT,"  an  ELEMENT  cannot  CONSIST  of  any  other  data  objects. 
The  CONSISTS  s'-atement  only  specifies  the  data  in  the  GROUP  and 
implies  nothing  about  its  format. 

CONSISTS  (CSTS) ; 

(list  of  group  and  element  names,  optionally 
preceded  by  system  parameters) 

A complete  problem  statement  should  have  all  GROUPS  broken  down 
to  smaller  GROUPS  and/or  ELEMENTS. 

The  ASSOCIATED  statement  specifies  those  RELATIONS  that  the 
CROUPS  or  ELEMENTS  are  associated  with.  This  implies  that  the 
information  in  the  GROUP  or  ELEMENT  is  in  neither  of  the 
ENTITIES  the  RELATION  is  BETWEEN. 

ASSOCIATED  (ASOD) ; 

(list  of  relation  names) 

The  TDENTI’='IES  statement  specifies  those  ENTITIES  for  which  the 
GROUP  or  ELEMENT  is  used  as  an  identification  key.  This  implies 
that  the  possible  values  of  the  GROUP  or  ELEMENT  are  all  unique. 
For  exaraole,  the  ULFMENT  which  represents  social  security  number 
in  ar  eraplo  yee  record  might  be  used  as  an  identifier. 

IDENTIFIES  (IDS) ; 

(list  of  entity  names) 

A CROUP  or  ELEMENT  may  identify  any  number  of  ENTITIES. 


3.9.3  Data- Per i vat  ion  Statements  for  GROUPS  and  ELEMENTS 

The  USED  statement  specifies  those  PROCESSES  which  use  the 
information  in  the  GROUP  or  ELEMENT. 

USED ; 

(list  of  process  names) 

This  statement  implies  (in  the  case  of  a GROUP)  that  at  least 
one  piece  of  data  in  the  GROUP  is  being  USED. 

To  specify  th^  manner  in  which  the  GROUP  is  USED  more  precisely, 
the  D’^PIVE  or  UPDATE  clause  may  be  used  in  conjunction  with  the 
eSFD  statement. 
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USED  BY  

(list  of  process  names) 

TO  DERIVE  (DRV)  ; 

(list  of  element,  group,  entity, 
set  ani  output  names) 

or  USED  by  a PROCESS  to  UPDATE  data; 

USED  BY ; 

(list  of  process  names) 

TO  UPDATE  (UOD) ; 

(list  of  element,  group,  entity, 
and  set  na  mes) 

The  DERIVED  statement  specifies  those  PROCESSES  that  derived 
some  information  presented  in  the  GROUP  or  ELEMENT. 

DERIVED  (DPVD) ; 

(list  of  process  names) 

This  statement  implies  (in  the  case  of  a GROUP)  that  at  least 
one  piece  of  data  (GROUP  or  ELEMENT)  in  the  GROUP  is  DERIVED. 

To  specify  more  precisely  the  manner  in  which  the  GROUP  or 
ELEMENT  is  derived,  the  USING  clause  may  be  used  in  Cv^njunction 
with  the  DERIVED  statement. 

DERIVED  BY  ( DRV  D)  

(list  of  process  names) 


USING ; 

(list  of  element,  group,  entity, 
set  and  input  names) 

the  UPDATED  statement  specifies  those  PROCESSES  that  modify  some 
information  presented  in  the  GROUP  or  ELEMENT. 

UPDAT'^D  (OPDD)  ; 

(list  cf  process  names) 

This  statement  implies  (in  the  case  of  a GROUP)  that  at  least 
one  piece  of  data  (GROUP  or  ELEMENT)  in  the  GROUP  is  UPDATED. 

To  specify  more  precisely  the  manner  in  which  the  GROUP  or 
ELEMENT  is  updated,  the  USING  clause  may  be  used  in  coniunction 
with  the  UPDATED  statement. 

UPDATED  BY  (UPDD)  

(list  of  process  names) 

US'^NG ; 

(list  of  element,  group,  entity, 
set  or  input  names) 


PART  T USER  REQUIREMENTS  LANGUAGE  MANUAL 


rBwl60/370/VS/’rSO  ORL  USER'S  MANUAL 


153 


Evprv  CROUP  inti  ELEMENT  t3f.f  ined  should  be  USED,  DERIVED  or 
UPDATED  by  s'-  leas'-  one  PROCESS. 

The  CLASSIFICAP TON  of  a CROUP  or  ELEMENT  may  be  specified  with 
♦■he  CLA  SST’=’TCATION  statement; 

ClAf SIFTCATION ; 

(list  of  classification  names,  each 
optionally  followed  by  a level  number) 

Anv  PROCESSES  or  PROCESSORS  that  use  the  GROUP  or  ELEMENT  must 
have  SECUPITY-ACCESS-PTGHTS  that  match  the  classification  of  the 
CPQUP  or  ELEMENT. 


3.9.4  System-Si ze  Statement  s for  ELEMENTS 

'♦'he  VALUE  statement  is  used  to  define  numeric  values  an  ELEMENT 
may  have.  A GROUP  cannot  have  a VALUE  directly  associated  with 
it.  The  VALUE  statement  may  only  specify  numeric  values  and 
does  not  imply  anything  about  storage  format,  etc.  The 
ATTPIBUTES  ani  DFSEFIPTION  statement  should  be  used  to  present 
this  type  of  information  as  well  as  to  specify  character  values. 

VALUF  (WAL)  ; 

(integer  value) 

Only  positive  integer  values  may  be  specified.  Decimal  numbers, 
negative  numbers,  etc.  are  not  acceptable. 

A range  of  valutas  may  also  be  specified. 

VALUES  (VAL)  THPU ; 

(minimum  value)  (maximum  value) 

Again,  the  values  must  be  positive  integers.  POSINF  and  NEGINF 
may  te  used  to  represent  positive  and  negative  infinity, 
respect ivel y . 

Only  one  VALUE  statement,  of  either  of  the  forms,  may  be  given 
to  describe  a particular  ELEMENT. 

3.9.5  Project- Management  Statemen  ts  for  GROUPS  and  EL  EH  ENTS 

The  RESPONSIULE-PPORLEM-DEFINER  statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.  2 . 

3.9.6  System-Proper  t ies  Sta  tement  s for  GROUPS  and  ELEHE  NTS 

•♦’he  SYNONYMS,  DESCRIFTTON,  SEE-MEMO,  KEYWORDS,  ATTRIBUTE, 

ASSEPT,  SFCUPTTY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
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this  Section.  Description  and  syntax  of  these  statenents  are 
qiven  in  section  3.2. 

3.10  PP^FSS  Section 

Tho  FP0CES5  is  used  to  define  the  function,  oc  functions  of  the 
tanet  system.  At  the  highest  level,  the  function  of  the  target 
system  may  be  defined  as  a single  PROCESS.  This  PROCESS,  could 
in  turn,  be  broken  down  into  more  detailed  PROCESSES.  It  is  the 
task  of  the  PROCESS  to  reference  and  manipulate  data  in  the 
target  system. 

PROCESS  (PRC) ; 

(list  of  process  names) 

3.10.1  System-F  low  f^tements  for  PROCESSES 

The  P^’CEIVES  statement  is  used  to  specify  that  the  PROCESS 
accepts  information  (INPUTS)  from  outside  the  target  system. 

RECEIVES  (RCVS)  ; 

(list  of  input  names) 

This  statement  only  specifies  that  the  INPUTS  are  accepted  by 
the  PROCESS  and  does  not  imply  that  the  information  in  the 
INPUTS  are  USED  or  how  it  is  USED  by  the  PROCESS. 

The  GENERATES  Statement  is  used  to  specify  that  the  PROCESS 
produces  information  (OUTPUTS)  for  use  outside  the  target 
system. 

GENERATES  (GENS) ; 

(list  of  output  names) 

This  statement  only  specifies  that  the  OUTPUTS  are  distributed 
by  the  PROCESS,  and  does  not  imply  that  the  information  in  the 
OUTPUTS  is  DEFIVED  by  the  PROCESS. 

"’hese  statements  imply  that  some  physical  processing  or 
translation  may  be  necessary.  The  RECEIVES  statement  means  that 
the  physical  media  containing  data  must  be  accommodated. 
Similarly,  the  GENERATES  statement  means  that  data  must  be 
recorded  in  whateyer  medium  has  been  chosen. 


3. 1C. 2 Systea-S  true  t ure  Sta  teaents  for  PROCESSES 

A PROCESS  may  be  part  of  one,  and  only  one,  larger  PROCESS,  and 
it  may  have  any  number  of  subparts  that  are  also  PROCESSES. 

OAPT ; 

(process  name) 


PART 
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‘PURPARTS  (SUBP) ; 

(list  of  process  names) 

""hese  statements  permit  organization  functions  and  programminq 
structures  to  be  defined  for  the  problem  statement. 

The  IITILITiEP  and  UTLIZES  statements  are  used  to  specify  that  a 
PROCESS  represents  a function  used  by  several  other  PROCESSES. 
Definition  of  UTILIZED  implies  that  the  PROCESS  is  common  to 
more  than  one  other  PROCESS.  If  not,  the  PROCESS  should  be 
defined  as  a SU3PAPT. 

UTILIZED  (UTLD)  ; 

(list  of  process  names) 

U'"TLIZES  (UTLS) ; 

(list  of  process  names) 

A giver  PROCESS  may  have  any  number  of  SOBPAPTS  and  UTILIZE  any 
number  of  other  PROCESSES.  A PROCESS  may  be  a SUBPART  of  only 
one  other  PROCESS,  but  be  UTILIZED  by  any  number  of  PROCESSES. 


3.10.3  Data- Per i vat  ion  Statements  for  PROCESSES 

The  USES  statement  specifies  those  SETS,  INPUTS,  ENTITIES, 
GROUPS  and  ELEMENTS  from  which  some  information  is  taken  and 
used  by  the  P’^OCESS  to  perform  its  designated  function, 

USES 

(list  of  sat,  input,  entity,  group  and  element  names) 

In  the  case  where  SET,  INPUT,  ENTITY  or  GROUP  names  are  given, 
this  statement  implies  that  at  least  one  ELEMENT  within  these 
are  USED  by  the  PROCESS. 

To  specify  the  manner  in  which  the  PROCESS  USES  the  data  more 
precisely,  the  DERIVE  or  UPDATE  clause  may  be  used  in 
coniunction  with  the  USES  statement. 

USES 

(list  of  set,  input,  entity,  group  and  element  names) 

•"O  DERIVE ; 

(list  of  set,  output,  entity, 
group  and  elamant  names) 


USES 

(list  of  set,  input,  entity,  group  and  element  names) 

TO  UPDATE ; 

(list  of  set,  entity, 
group  and  element  names) 
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The  DERIVES  statemant  specifies  those  SETS,  OUTPUTS,  ENTITIES, 
GROUPS  ani  ELEMENTS  for  which  some  information  is  derivei  by  the 
PROCESS  to  perform  its  desiqnated  function. 

DERIVES  (DRVS) ; 

(list  of  set,  output,  entity, 
group  and  element  names) 

In  the  case  where  SET,  OUTPUT,  ENTITY  and  GROUP  names  are  given, 
this  statement  implies  that  at  least  one  ELEMENT  within  these 
are  DERIVED  bv  the  PROCESS. 

■^o  specify  the  manner  in  which  the  PROCESS  DERIVES  the  data  more 
precisely,  the  USING  clause  may  be  used  in  congunction  with  the 
DERIVES  Statement. 

DERIVES  (DRVS)  

(list  of  set,  output,  entity, 
group  and  element  names) 


USING ; 

(list  of  set,  input,  entity, 
group  and  element  names) 

"^he  UPDATES  statement  specifies  those  SETS,  ENTITIES,  GROUPS  and 
ELEMENTS  for  which  some  information  is  updated  by  the  PROCESS  in 
performing  its  designated  function. 

UPDA-tES  (UPDS) ; 

(list  of  set,  entity, 
group  and  element  names) 

In  the  case  where  SET,  ENTITY  and  GROUP  names  are  given,  this 
statement  imolies  that  at  Least  one  ELEMENT  within  these  are 
UPDATED  by  the  PROCESS. 

To  specify  the  manner  in  which  the  PROCESS  UPDATES  the  data  more 
precisely,  the  USING  clause  may  be  used  in  conjunction  with  the 
UPDATES  Statement. 

UPDATES  (UPPS)  

(list  of  set,  entity, 
group  and  element  names) 


USING ; 

(list  of  set,  input,  entity, 
group  and  element  names) 

The  MAINTAINS  statement  specifies  those  RELATIONS  or 
SUBS*’TTING-CRIT2R10N  which  are  maintained  by  the  PROCESS. 
Maintenance  of  RELATIONS  normally  involves  addition  and  deletion 
of  connections  be^’ween  ENTITIES  whereas  maintenance  of 
SURSETTTNG-CRIT EPION  deals  with  placement  of  ENTITIES,  INPUTS 
and  OUTPUTS  in  proper  SETS  according  to  the  values  of  the 
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ELEMENTS  and  GROUPS  contained  within  those  designated  as 
SUBSETTING-CRITERION  nanes. 

MAINTAINS  (MTNS)  ; 

(list  of  relation  and 
subsetting  criterion  names) 

Every  t>t^0CESS  should  be  defined  to  interact  with  data  in  some 
manner  (DERIVES,  USES,  UPDATES  or  MAINTAINS). 

'^he  PROCEDURE  statement  is  used  to  specify  an  algorithm  of  the 
function  of  the  PROCESS.  The  PROCEDURE  statement  is  a comment 
entry  statement  thus  allowing  any  form  of  procedure 
specification  to  be  given  such  as  decision  tables,  actual 
program  code,  narrative  format,  etc. 

PROCEDURE  (PPCD) ; 


(comment  entry) 

Every  PROCESS  that  does  not  have  SUBPARTS  or  does  not  UTILIZE 
any  other  PROCESSES  should  have  a PROCEDURE  statement  that 
specifies,  in  sufficient  detail  for  implementation,  the  rules 
for  carrying  out  its  function. 

The  SECURITY-ACCESS- RIGHTS  of  a PROCESS  may  be  specified  with 
the  SECURITY-ACCESS-RIGHTS  Statement; 


SECURITY-ACCSSS-RIGHTS  

(list  of  classification  names, 
each  optionally  followed 
by  a level  number) 


A PROCESS  that  uses,  derives  or  updates  data  must  have 

SEC  UPI'^Y-ACCESS-RTGHTS  that  match  the  classification  of  the 

data. 


3.10.U  System-Size  State  men  ts  for  PROCESSES  ! 

1 

The  HAPPENS  statement  is  used  to  specify  the  frequency  of  a 

PROCESS  in  a given  time  interval.  I 

HAPPENS  (HAP) TTMES-PER  (TIMP) ; li 

(system  parameter)  (interval  name)  '-i 

t| 

Every  PROCESS  should  have  one,  and  only  one,  HAPPENS  statement 
associated  with  it. 

3.10.5  System-Dynamics  Statements  for  PROCESSES 

•^he  TRIGGERED,  TERMINATED  and  INTERRUPTED  statements  are  used  to 
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specify  those  EVENTS,  INPUTS,  PROCESSES  and  CONDITIONS  that 
affect  the  initialization  of  processing,  or  the  halting  of 
process inq. 


TSIGGFPED  BY  (TRGD)  


(list  of  event,  input  and/or  process  namesi 


TRIGGEFED  WHEN  (TPGD) 


.BECOMES  TRUE  (T)  ; 


(condition  name) 


TRIGGERED  WHEN  (TRGD) 


.BECOMES  FALSE  (F)  ; 


(condition  name) 


TERMINATED  BY  (TFKD) 


(list  of  event,  input  and/or  process  names) 

TERMINATED  WHEN  (TRMD) BECOMES  TRUE  (T); 

(condition  name) 

TERMINATED  WHEN  (TRMD) BECOMES  FALSE  (F)  ; 

(condition  name) 


INTERRUPTED  BY  (INTD)' 


(list  of  event,  input  and/or  process  names) 

INTERRUPTED  WHEN  (INTD) BECOMES  TRUE  (T)  ; 

(condition  name) 

INTERRUPTED  WHEN  (INTD) BECOMES  FALSE  (F)  ; 

(condition  name) 

PROCESSES  may  also  TRIGGER,  TERMINATE  and  INTERRUPT  other 
PROCESSES. 


TRIGGERS  (TPGS) ; 

(list  of  process  names) 

TERMINATES  (TPMS) ; 

(list  of  process  names) 

INTERRUPTS  (INTS) ; 

(list  of  process  names) 

PROCESSES  may  also  generate  EVENTS  and  set  values  of  CONDITIONS. 
An  EVENT  may  be  generated  either  at  the  initiation  of  a PROCESS 
or  when  it  finishes. 

INCEPTION-CAUSES  (INCC) 

(list  of  event  names) 

TERMINATION-CAUSES  (TERC)  

(list  of  event  names) 

MAKES TRUE  (T)  ; 
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(list  of  condition 


nanes) 


MAKES FALSE  (F)  ; 

(list  of  condition  names) 

A PROCFSS  lay  or  may  not  be  involved  in  any  system  dynamics 
relationshi ps. 


3.10.6  Syst ei-A rchi tectuce  Sta tewen ts  f or  PROCESS BS 

The  PERFORMED  statement  specifies  the  physical  PROCESSOR  (e.g., 
hardvare  or  organizational  unit)  which  performs  the  functions 
described  by  the  PROCESS. 

PERFORMED  (PRMD) ; 

(name  of  processor) 

Every  PROCESS  should  be  PERFORMED  by  some  PROCESSOR. 

The  RESOURCE-USAGE  statement  indicates  resource  consumption 
associated  with  the  PROCESS. 

pi's OURCE-ns  AGE  (RU) FOR ; 

(system  parameter)  (name  of  resource- 


usage- pa  rame  ter) 


3.10.7  Project- Management  Statements  for  PROCESSES 

The  PESPONSIBLE-PPOBLEM-DEFINEB  statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.2. 


3.10.8  System- Proper  tv  Statements  for  PROCESSES 

The  SYNONYMS,  D'='SCRT  PTION,  SEE-MEMO,  KEYWORDS,  ATTRIBUTE, 

ASSERT,  SECURITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3.2. 


3.11  INTEPV  AL  Section 

An  INTERVAL  is  used  to  define  a segment  of  time.  A week  or  day 
are  simple  examples  of  INTERVALS. 

INTERVAL  (INT) ; 

(list  of  interval  names) 

It  is  important  to  note  that  unless  defined  as  a SYNONYM,  WEEKS 
is  not  the  same  as  WEEK.  In  most  cases,  it  is  desirable  that 
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both  names  represent  the  sam-a  interval. 

1.11.1  System- St  rue tare  Statements  for  INTEPVALS 

The  CONSISTS  statement  specifies  the  smaller  INTERVALS  that  the 
INTERVAL  can  be  broken  down  to. 

CONSISTS  (CSTS) ; 

(list  of  interval  names,  each 
optionally  preceded  by 
a system  parameter) 

The  SYSTEM- P AF A MET E R should  be  specified  to  make  the 
relationship  between  intervals  meaningful.  It  makes  little 
sense  to  say  that  a year  consists  of  weeks  without  the 
ouantitative  property. 

1.11.2  Proi ect- Hana gement  Statements  fo r INTERVALS 

The  PESPONSIBLE-PPOBLEM-DEFINEP  statement  may  be  used  in  this 
Section.  Description  and  syntax  for  this  statement  are  given  in 
section  3.2. 

3.11.3  System- Proper ties  St  atements  for  INTERVALS 

The  SYNONYM,  DESCRIPTION,  SEE-MEMO,  KEYWORDS,  ATTRIBUTE,  ASSERT, 
SECUPITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in  this 
Section.  Description  and  syntax  of  these  statements  ate  given 
in  section  3.2. 


3.12  CONDITION  Section 

A CONDITION  designates  some  situation  that  the  problem  definer 
wants  to  identify  because  it  influences  the  reguirements  for  the 
system. 

CONDITION  (CONO)  ; 

(list  of  condition  names) 

The  first  of  the  month  may  represent  some  CONDITION  for  which 
action  of  the  target  system  would  occur  depending  on  the  state 
of  the  CONDITION. 

3.12.1  Syst em-D ynam ics  Stat ements  for  CONDITIONS 

The  TRUE  WHILE  and  FALSE  WHILE  statements  specify  those 
situations  when  the  CONDITION  is  in  the  TRUE  state,  or  in  the 
FALSE  state,  respectively.  This  information  is  presented  in  a 
comment  entry  format. 
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TRUE  WHILE; 


(coinent  entry) 


FALSE  WHILE; 


{comment  entry) 

Every  CONDITION  should  have  a TRUE  WHILE  or  a FALSE  WHILE 
sta  tement. 

A CONDITION  can  be  set  by  a PROCESS,  an  EVENT  or  the  arrival  of 
an  INPUT. 

MADE  TRUE  BY ; 

(list  of  processes,  events  and/or  inputs) 

MADE  FALSE  BY ; 

(list  of  processes,  events  and/or  inputs) 

The  change  in  state  of  a CONDITION  may  also  affect  the 
processing  being  performed,  or  may  initiate  new  processing. 


BECOMING 

(BFCG) 

TRUE  (T) 

TRIGGERS  (TRGS) 

(list 

of 

process 

names) 

BECOMING 

(BECG) 

FALSE  (F) 

TRIGGERS  (TRGS) 

. 

(list 

of 

proca  ss 

names) 

BECOMING 

(BECG) 

TPUE  (T) 

TERMINATES  fTRMS) 

« 

(list 

of 

proce  ss 

names) 

BECOMING 

(BECG) 

FALSE  (F) 

TERMINATES  (TRMS) 

. 

(list 

of 

process 

names) 

BECOMING 

(BECG) 

TPUF  (?) 

INTERRUPTS  (INTS) 

; 

(list 

of 

process 

names) 

BECOMING 

(BECG) 

FALSE  (F) 

INTERRUPTS  (INTS) 

(list 

of 

process 

names) 

The  change  in  state  of  a 

condition  may  cause  an 

EVENT. 

BECOMING 

(BECG) 

TPUE  (?) 

CAUSES  fCSS) 

t 

(list  of 

event  names) 

BECOMING 

(BECG) 

FALSE  (F) 

CAUSES  (CSS) 



(list  of  event  names) 


A CONDITION  should  interact  in  some  way  with  at  least  one  EVENT 
or  FFOCESS. 
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3.12.2  Project- Man  a rjement  Statements  for  CONDITIONS 

The  PESPONSIBLE-PPOBLFM-DEFINER  statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.  2 . 


3.12.3  SvsteiB-P  rope  r ties  Statements  for  CONDITIONS 

The  SYNONYMS,  D ESCo  ^ p-ri  ON , SEE-MEMO,  KEYWORDS,  ATTRIBUTE, 

ASSERT,  SECURITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3.2. 


3.13  EVINT  Soct  ion 

An  EVENT  defines  an  occurrence  of  something  within  the  system. 
The  state  of  a CONDITION,  initiation  of  a PROCESS,  etc.  may  be 
defined  as  EVENTS. 


EVENTS  (BV) 


(list  of  event  names) 


An  EVENT  occurs  at  a given  instant  in  time  and  is  used  in  the 
problem  statement  to  relate  the  things  that  go  on  in  the  system 
with  time. 


5.13.1  System- Dynamics  Stat  ements  for  EVENTS 

An  EVENT  may  be  caused  by  a PROCESS  (either  on  inception  or  on 
termination),  a CONDITION,  an  INPUT  or  another  EVENT. 


CAUSED  BY  (CSD) 


(list  of  event  and/or  input  names) 


CAfTSEB  WHEN  (CSD) BECOMES  TRUE  (T)  ; 

(condition  name) 


CA'iSED  WHEN  (CSD) 


BECOMES  FALSE  (F)  ; 


(condition  name) 


ON  INCEPTION  (TNCP) 


(list  of  process  names) 


ON  TERMINATION  (TFPK) 


(list  of  process  names) 


An  EVENT  may  cause  another  EVENT  or  set  the  value  of  a 
CONDITION. 


CAUSES  (CSS) 

(list  of  event  names) 
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MAKES  (MXK) 


TRUE  (T)  ; 


(list  of  condition  names) 


MAKES  (MAK) 


.FALSE  (F)  ; 


(list  of  condition  names) 

An  EVENT  may  affect  processing,  or  initiate  new  procesing. 
TRIGGERS  (TRGS) ; 


(list  of  process  names) 


■ERMINATES  (TRES) 


(list  of  process  names) 


INTERRUPTS  (INTS) 


(list  of  process  names) 

An  EVENT  should  interact  with  at  least  one  CONDITION  or  PROCESS. 

The  HAPPENS  statement  specifies  the  frequency  of  the  EVENT  in 
the  target  system  for  a given  time  interval. 

HAPPENS  (HAP)  TIHES-PER  (TIMP) ; 

(system  parameter)  (interval  name) 

Every  EVENT  should  have  one,  and  only  one,  HAPPENS  statement. 

3.13.2  Project- Man a qement  S ta tements  for  EVENTS 

The  EESPONSIHLE-PROBLEH-DEFINEB  statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.2. 

3.13.3  Syst  em-Proper ties  St  atements  for  EVENTS 

The  SYNONYMS,  DESCRIPTION,  SEE-MEMO,  KEYWORDS,  ATTRIBUTE, 

ASSERT,  SECURITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  ate 
given  in  section  3.2. 

3.14  PROCESSOR  Section 

A PROCESSOR  is  an  object  that  can  "perform"  a PROCESS.  That  is, 
a PROCESSOR  is  an  "agent,"  such  as  a computer  system, 
organizational  unit,  or  person,  that  physically  acts  to  perform 
a PROCESS. 


PROCESSOR  (PRCR)  


(list  of  processor  names) 


3.14.1  System-S  true ture  Sta  tements  for  PROCESSORS 
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A PFOCFSSOP  nay  be  part  of  one,  and  only  one,  larger  PROCESSOP, 
and  it  aay  have  any  nunber  of  subparts  that  are  also  PROCESSOPS. 

PAP"^ ; 

(processor  naae) 

SUBPARTS  (StJBP)  ; 

(list  of  processor  names) 


1.14.2  Data- Per i vat i on  Statements  for  PROCESSORS 

In  the  target  systea,  PROCESSOR  aay  have  the  tight  to  access 
information  of  certain  classifications  and  categories. 

SECnPITY-ACCESS=RIGHT  (SAR) 

(list  of  classification  names 
optionally  followed  by 
classification  levels) 


3.14.1  Syst em-A rchi tecture  Statements  for  PROCESSORS 

A PRCCESSOR  may  CONSUME  RESOURCES,  such  as  CPU-time,  elapsed 
time,  or  memory. 

CONSUMES  (CNSS) 

(name  of  resource) 

RATE 

(system  - parameter) 

PER ; 

(name  of  resource-usage-parameter) 

A PROCESSOR  is  the  object,  group  or  person  that  performs  the 
functions  specified  by  one  or  more  PROCESSES. 

PERFORMS  (PFMS)  ; 

(list  of  process  names) 

1.14.4  Project- Management  Statements  for  PROCESS ORS 

The  RFSPONSIBLE-PROBLEM-DEFINEP  statement  may  be  used  in  this 
Section.  Description  and  syntax  for  this  statement  are  given  in 
section  3.2. 


3.14.5  System-Property  Statements  for  PROCESSORS 

The  SYNONYMS,  DESCRIPTION,  SEE-MEMO,  KEYWORDS,  ATTRIBUTE, 

ASSEFT,  SECURITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  for  these  statements  are 
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qiven  in  section  3.2. 


3.15  PISOnpCF  Section 

A RESOURCE  is  somethinq  that  the  physical  elenents  of  the  target 
system  consume  in  order  to  carry  out  information  processing 
f unctions. 

RESOURCE  (RSC) ; 

(name  of  resource) 


3.15.1  S^stem^A rchi tecture  Sta tewen ts  for  RESOURCES 

A PESOnpCE  may  be  consumed,  or  used  up,  by  a PROCESSOR. 

CONSUMED  (ONSD) 

(list  of  processor  names) 

PATE PER ; 

(system  parameter)  (name  of  resource- 

usage-parameter)  . 

Resource  usage  must  be  measured  in  some  unit,  such  as 
milliseconds  or  feet. 

MEASURED  (M  SRD) ; 

(name  of  unit) 


3.15.2  Pro-)ect-  Management  statements  for  RESOURCES 

The  RES PONSI BLS-PPO BLEM-DEP INER  statement  may  be  used  in  this 
Section.  Description  and  syntax  for  this  statement  are  given  in 
section  3.2. 


3.15.3  System- Proper  tv  Statements  for  RESOURCES 

The  SYNONYMS,  DESCRIPTION,  SEE-MEMO,  KEYWORDS,  ATTRIBUTE, 

ASSER''’,  SECUPITY,  SCUPCF  and  THaCE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  for  these  statements  are 
given  in  section  3.2. 


3.16  RESOURCE- US  AGE- PARAMETER  Section 

A PESOUPCE-USAG E-PAF AMETER  is  an  object  that  defines  a measure 
of  the  RESOURCE  usage  for  a PROCESS.  It  is  used  to  express 
resource  consumption  of  a PROCESSOR  performing  a PROCESS 
independent  of  what  PROCESSOR  performs  it. 


RESOURCE-USAGE- PAPA  METER  (RUP) 
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(name  of  resource- 
usag  e-parameter) 

3.16.1  Syst  em- A rchi t get u re  5ta  tements  for  R HSOU  PCE- U S A3  E- 
PARAHFTEis 

A particular  value  for  RESOURCE  usage  may  be  associated  with  a 
given  PROCESS. 

RESOOPCE-nSAG'='-  PAP  A M ETE  P- VA  LUE  (PUPV) 

(system  parameter) 

FOB ; 

(name  of  process) 

3.16.2  Project- Management  S ta tements  for  HESOURCE-USASE- 
PARA  MiTERs"" 

The  PESFONSIBLF-PPnBLEM-DEFINER  statment  may  be  used  in  this 
Section.  Description  and  syntax  for  this  statement  are  given  in 
section  3.2. 

3.16.3  System-P  rope  r ty  Sta  tements  for  RESOURCE- USAGE-PARA  MITERS 

'"he  SYNONYMS,  DESCRIPTION,  SEE-MEMO,  KEYWORDS,  ATTRIBUTE, 

ASSERT,  SECURITY,  SOURCE  and  TPACF-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  for  these  statements  are 
given  in  section  3.2. 

3,17  UNIT  Section 

A UNIT  is  used  to  measure  RESOURCES.  For  example,  possible 
UNITS  would  include  inches  and  kilowatt  hours, 

UNIT ; 

(name  of  unit) 

3.17.1  System- Architecture  Statements  for  I) N ITS 

A UNIT  must  be  associated  with  the  RESOURCES  it  is  used  to 
nea  sur e , 

MEASURES  (MSRS) ; 

(list  of  resource  names) 

3.17.2  Project- Man  a qemen  t S ta  tements  £or  UNITS 

"•ne  F«'«'PONSI  BLP-PROPLFM-DEFINEP  statement  may  be  used  in  this 
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SGct-ion.  Description  and  syntax  for  this  stateaent  are  given  in 
section  3.2. 


3.17.3  SysteiB-P  ropa  cty  Statements  for  UNITS 

The  SYNONYHS,  DESCRIPTION,  SEE-MFKO,  KEYWORDS,  ATTRIBUTE, 

ASSERT,  SECURITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  for  these  statements  are 
given  in  section  3.2. 

3.18  PFOBLEMrP? finer  Section 

'"he  FPOPLEN-DF’RINFF  is  that  oerson  responsible  for  one  or  more 
sections  of  th^  URL  Problem  Statement.  In  most  cases,  this  is 
'■he  person  who  originally  wrote  those  URL  statements. 

PROBLEK-DE'RINFF  (PD) ; 

(list  of  problem  definer  names) 


3.18.1  Project -Management  Statements  for  PROBLEM- DEFINER 

The  RESPONSIBLE  statement  is  used  to  specify  those  URL  sections 
for  which  the  PROBLEM-DEFINER  is  responsible. 

RESPCKSIBLE  (^ESP) ; 

(list  of  names) 

A PROBLEM-DEFINER  cannot  be  RESPONSIBLE  for  other 
PFOBIEM-DEFINERS. 

A PROBLEM-DEPIMEP  should  be  RESPONSIBLE  for  at  least  one  name. 

The  MAILBOX  statement  specifies  an  address  for  the 
PROBLEM-DEFINER  to  which  comments  or  questions  concerning  the 
problem  statement  can  be  sent. 

MAILFOX  (BOX) ; 

(name  of  mailbox) 

A PROBLEM-DE'^INEP  may  have  only  one  MAILBOX. 


3.18.2  System- Proper  ties  St  atemen  ts  for  PROBLEM-DEFINER  S 

""he  SYNONYMS,  DESCRIPTION,  SEE-MEMO,  KEYWORDS,  ATTRIBUTES, 
ASSERT,  SECURITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3.2. 


3.19  MEMO  S ecti on 
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A MEMO  is  a narrative  description  which  applies  to  more  than  one 
name  in  the  oroblpm  statement. 

MEMO ; 

(memo  name) 

'''he  text  of  the  MEMO  should  be  put  in  the  DESCRIPTION  statement. 

3.19.1  Project- Man a ge men t Sta  tements  for  MEMOS 

The  PESPONST3LR-PPORLEM-DEFINER  statement  may  be  used  is  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.2. 


3.19.2  Syst  em- Proper  ties  St  atements  for  MEMOS 

The  SYNONYMS,  DESCRIPTION,  KEYWORDS,  ATTRIBUTES,  ASSERT, 
SECURITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in  this 
Section.  Description  and  syntax  of  these  statements  are  given 
in  section  3.2. 

The  APPLIES  Statement  specifies  those  URL  names  to  which  the 
MEMO  pertains. 


APPLIES  (APP) 


(list  of  names) 


A MEMO  cannot  APPLY  to  another  MEMO  name. 


A MEMO  should  APPLY  to  at  least  two  names.  Otherwise,  the 
information  could  be  presented  in  the  DESCRIPTION  statement  for 
the  name. 


3.20  The  0EFtn2  Section 

The  DEFINE  section  is  used  to  specify  information  about  special 
types  of  names  that  do  not  have,  their  own  URL  sections. 

The  format  of  the  DEFINE  section  is: 

DEFINE  (DSF) name-type; 

(URL  names) 

Where  the  name-type  may  be  one  of  the  following: 

ATTPIBUtE  (ATTR)  - defines  a characteristic  or  mode  of 

the  target  system. 

A TTRTBUTE- V ALUE  (ATtV)  - defines  a particular  value  for  an 

associated  ATTRIBUTE. 
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CLASSIFICATION  (CLS ) 
KEYHOFD  (KEY)  - 

MAILBOY  (BOX)  - 
SECURITY  (SEC)  - 


can  be  associated  with  data 
processes  and  processors. 

can  be  related  to  names  for 
retrieval  and  analysis  purposes. 

defines  an  address  for  a 
PPOBLEM-DEFINER . 

defines  security  status  for  one  or 
more  URL  names. 


SOURCE  (SRC)  - defines  a reference  for  additional 

information  related  to  objects 
being  described. 

SUBSE'^TING-CPITEPIOW  (5SCN)  - 

defines  some  data  objects  whose 
value  is  used  as  the  criterion  for 
segmenting  a SET  of  data. 

SYSTEM- PARAMETER  (SYSP)  - defines  an  object  whose  value 

influences  the  size  of  particular 
aspects  of  the  system. 


TRACE-KEY  (TKEY) 


can  be  used  to  relate  names  which 
exist  in  different  data-bases. 


3.2  0.1  System- Structure  Sta tements  for  the  DEFINE  Section 

SUBSETTINO-CRITBRION  names  may  be  defined  to  apply  to  one  or 
more  SETS  via  the  SUBSETTIN  G-CRITERION  statement. 


SUPSETTING-C^ITEPTON  (SSCN) 


(list  of  set  names) 


No  ether  name  types  in  the  DEFINE  section  may  use  this  j 

statement.  | 

3.20.2  Data- Per i vat  ion  Statements  for  the  DEFINE  Section  j 

The  MAINTAINED  statement  specifies  those  PROCESSES  that  maintain  ' 

SUB  SETTING- CRITEPIO N for  organization  of  a SET. 

MAINTAINED  (MNTP) ; ^ 

(list  of  process  names) 

Maintenance  of  SUBS ETTING-CRITEPION  involves  placement  of 
ENTITIES,  INPUTS  and  OUTPUTS  in  proper  SETS  according  to  the 
values  of  the  S UBSETTING-CRITERION  contained  within  them. 

No  other  name  types  in  the  DEFINE  section  may  use  this  ! 
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sta  tf mRnt. 


3.2  0.3  SysteiB-S  izp  Sta  teaipn  ts  for  t he  DEFINE  5.SSti2!i 


SYSTEM- PAPAM ETE PS  and  ATTPI BUTE- V AL UES  may  be  defined  to  have  a 
VALUE  or  range  of  VALUES  associated  with  them. 

The  VALUE  statement  is  used  to  define  the  numeric  values  a 
SYSTEM-PARAHETEP  may  have. 

VALUE  (VAL) ; 


(integer  value) 


Only  positive  integer  values  may  be  specified.  Decimal  numbers, 
negative  numbers,  etc.,  are  not  acceptable. 


A range  of  VALUES  may  also  be  specified. 

VALUTAS  (VAL)  T'HPU ; 

(minimum  value)  (maximum  value) 

Again,  the  VALUES  must  be  nositive  integers.  The  rainioum  value 
must  be  less  than  the  maximum  value.  PCSINF  and  NEGINF  may  be 
us^d  to  represent  positive  and  negative  infinity,  respectively. 

Only  one  VALUE  statement,  of  either  of  the  forms,  may  be  given 
to  describe  a particular  SY STEM-PAP AMETEP . 

Vo  other  name  types  in  the  DEFINE  section  may  use  this 
statement. 


3.20.4  Project- Management  S ta  tements  for  the  DEFINE  Sec  ti on 

"^he  RFSPONSIBLE-PROBLEM-DEFIVEP  statement  may  be  used  in  this 
Section.  Description  and  syntax  for  these  statements  are  given 
in  section  3.2. 

3.2C.S  Svstem-P  rope  r ties  St  atemen  ts  for  the  DEFINE  Sect  ion 

The  SYNONYMS,  D ESCP I P^ION,  SEE-MEMO,  KEYMOPDS,  ATTRIBUTES, 
ASSEP-^,  SECURITY,  SOURCE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3.2. 

The  APPLES  Statement  may  be  used  for  MAILBOXES,  SECURITIES  and 
SOURCES  to  specify  the  UFL  names  that  they  apply  to. 

APPLIES  (APP) ; 

(list  of  names) 

Exceptions  are  that  SECURITY  may  not  have  SECURI'^Y,  and  SOURCES 
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may  not  have  a SOURCE. 


3.21  The  DESIGNATE  Section 


The  DESIGNA'^’E  section  consists  of  one  statement  which  specifies 
that  a qiven  name  is  to  be  made  a SYNONYM  of  another  name. 


This  facilitates  the  advantage  of  using  short  abbreviations  when 
referencing  a particular  object. 


DESIGNATE  (DESG) AS  A SYNONYM  (SYN)  ; 

(a  name) 


A name  can  have  any  number  of  SYNONYMS,  but  a name  can  be  a 
SYNCNYM  for  only  one  other  name. 


No  other  statements  are  allowed  in  this  section. 


4.  STRATEGY  IN  USING  URL 


! : 
i 

1 , 


URL  is  a very  flexible  and  comprehensive  language.  Most 
situations  can  be  represented  or  expressed  in  URL  in  more  than 
one  way;  each  of  which  is  syntactically  correct.  However,  the 
different  representatives  may  imply  different  semantics  which 
mav  or  may  not  be  what  the  analyst  intended.  This  section 
describes  a number  of  situations  in  which  alternative  methods  of 
expression  are  possible  and  outlines  the  implications  of 
different  strategies. 


4 . 1 Specifying  the  " System”  Boundar v 

In  URL,  a UFA  data-base  contains  the  description  of  one  system. 
Each  system  has  a boundary  and  the  system  description  may  be 
thought  of  as  consisting  of  two  parts: 

- the  specification  of  what  goes  on  inside  the  system. 

- the  specification  of  what  crosses  the  boundary. 

Alternative  strategies  are  possible  in  the  order  in  which  these 
parts  are  specified.  One  possibility  is  to  delineate  the 
boundary  first.  The  second  is  to  describe  the  "interior"  of  the 
system  without  identifying  the  boundary. 


1)  Specifying  *;he  Boundatj  First 

A firm  boundary  is  obtained  when  INTERFACES  are  defined  and 
their  communication  with  the  system  is  specified  by  naming 
INPUTS  and  OUTPUTS.  It  is  assumed  here  that  INPUTS  enter  the 
system,  and  OUTPUTS  leave  the  system,  in  some  physical  form 
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containinq  data  values.  The  constraint  in  URL  is  that  an  INPUT 
can  only  come  from  an  INTERFACE  and  OUTPUTS  only  go  to  an 
INTEPFACE.  Inside  the  system,  a number  of  PROCESSES  may  be 
names,  each  one  of  which  uses  data  from  the  available  sources  - 
INPUTS,  ENTITIES  or  SETS,  or  from  unspecified  sources  - GROUPS 
and  ELEMENTS,  to  derive  and  update  data.  A PROCESS  may  USE  data 
from  any  of  these  sources  or  DERIVED  from  any  PROCESS;  and 
similarly,  d ata  DSPIVED  by  one  PPOCESS  may  be  USED  by  any  number 
of  other  PROCESSES. 

One  benefit  of  this  approach  is  that  the  problem  statement  can 
he  checked  for  completeness,  e.q.,  that  each  INPUT  is  GENERATED 
bv  some  INTERFACE  and  RECEIVED  by  at  least  one  PROCESS  and  that 
each  OUTPUT  is  GENERATED  by  some  PROCESS  and  RECEIVED  by  at 
least  one  INTER'^'ACF.  Another  benefit  is  that  the  description  of 
the  INPUTS  and  OUTPUTS  can  be  agreed  to  by  '■he  relevant 
INTEPFACE. 

A disadvantage  of  this  approach  is  that  an  INTEPFACE  is  not  a 
PPOCESS  and  an  ob-ject  that  is  an  INPUT  to  the  system  cannot  also 
be  an  OUTPUT. 


2)  Specifying  the  Interior  of  tjie  System  First 

In  some  cases,  it  may  be  desirable  to  delay  specifying  the 
system  boundary  until  the  interior  of  the  system  has  been 
described.  This  can  be  done  by  not  identifying  any  INPUTS  and 
OUTPUTS,  but  instead,  defining  those  PROCESSES  that  USE  and 
OEPTVE  data  and  defining  data  in  terms  of  ENTITIES,  SETS,  GROUPS 
and  ELEMENTS.  What  would  be  an  INTERFACE  in  the  previous  case, 
now  can  be  identified  as  a PROCESS,  and  therefore,  the  object  in 
the  real  world  can  use  data  from  any  source-derived  data  which 
can  be  used  by  anv  other  PROCESS, 

The  advantage  of  this  approach  is  that  any  of  the  objects,  e.g. , 
PROCESS,  can  both  USE  data  and  DERIVE  data  and  that  a given 
collection  of  data  identified  as  an  ENTITY  can  be  both  USED  by  a 
PROCESS  and  be  DEPTVED  by  a PROCESS  (in  addition  of  coarse  to 
being  UPDATED)  . 


1 


i 

i 

<1 


I 

I 


^•2  Assignment  of  Name  T^pes 

URL  requires  that  each  name  (object)  used  in  the  system 
description  be  of  a certain  type.  There  are  29  types  available 
of  which  20  are  defined  by  their  own  sections  and  the  other  9 
are  defined  by  the  DE^'INF  section. 

The  assignment  of  a type  to  a name  is  crucial.  Statements  that 
can  be  made  about  an  object  and  its  relationship  to  other 
objects  are  limited  to  those  available  in  the  object's  section. 
In  some  situations  the  choice  of  a type  for  a particular  object 
is  clear;  in  other  situations  there  may  be  several  legitimate 
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choices.  This  section  discusses  the  situation  in  which  there 
are  alternatives. 


h . 2 . 1 INTERFACES  Versus  PROCESSES 

Tn  very  qeneral  terms,  a PROCESS  is  an  obiect  which  is  part  of 
the  target  system,  and  which  operates  on  data  values  which  it 
USES  to  DERIVE  new  data  values.  The  PROCESS  can  also  UPDATE 
data.  The  data  which  is  used  by  a PROCESS  can  come  "from”  any 
other  PROCESS,  and  the  data  which  is  DERIVED  can  be  USED  by  any 
other  PROCESS. 

In  contrast,  an  INTERFACE  is  a unit  outside  the  boundary  of  the 
target  system  which  can  produce  data  for  the  target  system 
(OENFPATE  an  INPU’’’)  and/or  receive  data  from  the  target  system 
(RECEIVE  an  OUTPUT)  . 

An  object,  therefore,  should  be  assigned  an  INTERFACE  type  name 
only  if  it  interacts  with  the  target  system,  namely,  that  it 
will  either  RECEIVE  or  GENERATE  data.  Otherwise,  the  object 
should  be  assigned  the  name  type  "PROCESS." 


4.2.2  INPUTS.  OUTPUTS  and  ENTIRES 

INPUTS,  OUTPU-^S  and  ENTITIES  are  types  of  objects  which 
"contain"  or  "carry"  sets  or  collections  of  data  values. 
Conceptually,  the  name  can  represent  both  the  "container"  or  the 
collection  of  data  values  contained  in  that  container, 
’furthermore,  the  container  can  be  regarded  as  physical,  that  is, 
a card,  a taoe,  a record  on  a disc,  etc.,  or  it  can  be  regarded 
as  a logical  cons'-ruct  which  may  or  may  not  he  physically 
implemented  in  that  form. 

An  object  should  be  designated  as  in  INPUT  if  what  is  to  be 
specified  is  a container  with  data  values  coming  into  the  target 
system  from  outside,  i.e.,  from  an  INTERFACE. 

Another  distinguishing  characteristic  of  INPUTS  and  OUTPUTS  is 
that  when  interpreted  as  "containers"  of  data  values  they  are 
temporary  as  far  as  the  target,  system  is  concerned.  There  may 
be  multiple  instances  of  the  particular  INPUT  coming  in,  but 
once  it  is  received  by  a PROCESS,  the  particular  instance 
disappears. 

For  exaraDle; 


INPUT  time-card 

imolies  that  ♦■he  system  will  receive  objects  of  type  INPUT  which 
are  called  time-card.  The  number  of  individual  'time-cards' 
which  arrive  is  specified  by  the  .statements  such  as  HAPPENS. 
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Similarly,  an  ob-jpct  should  be  designated  an  OUTPUT  if  it  is  a 
"container"  of  data  values  and  if  it  is  specified  to  leave  the 
target  system.  Again,  there  may  be  multiple  instances,  each  one 
of  which  has  to  be  GRNEPATET)  and  each  leaves  the  system.  Once 
individual  instances  of  the  OUTPUT  have  left  the  target  system, 
they  are  not  considered  part  of,  or  accessible  to,  the  target 
system . 

The  reasons  for  distinguishing  INPUTS  and  OUTPUTS  from  ENTITIES 
and  GROUPS  is  that  (1)  eventually  the  physical  medium  on  which 
they  appear  and  their  representation  will  have  to  be  specified, 
and  (2)  the  source  and  destination  can  be  related  to  INTERFACES, 
and  (3)  time  and  volume  can  be  specified  for  INPUTS  and  OUTPUTS 
but  not  for  GROUPS. 

An  ENTITY  is  a "container"  of  data  value;  in  this  respect  it  is 
equivalent  to  an  INPUT  or  OUTPUT.  However,  it  differs  from 
INPUTS  and  OUTPUTS  in  that  it  is  internal  to  the  system  and  it 
oersists.  Therefore,  an  individual  instance  of  an  ENTITY  must 
be  created,  i.e.,  DERIVED. 

Again,  the  ENTITY  may  be  a "logical"  collection  of  data  values 
or  may  be  a "physical"  collection.  When  it  is  designated  as 
a physical  collection,  it  will  probably  be  implemented  as  a 
logical  record  or  physical  record  which  is  maint-ained  by  the 
system  in  some  way. 

Therefore,  an  object  which  is  a collection  of  data  values  that 
is  internal  to  the  target  system  and  persists  in  the  system, 
should  be  designated  an  ENTITY  rather  than  as  an  INPUT  or 
OUT  PUT. 


4.2.3  F N^TI^  Vers  us  GROUPS 

An  ENTITY  is  a logical  collection  of  data  values.  Data  values 
are  particular  instances  of  ELEMENT?  or  GROUPS.  The  data  values 
included  in  the  collection  are  specified  by  the  CONSISTS  of 
statement.  A GROUP  is  also  specified  as  CONSISTING  of  a number 
of  GROUPS  and/or  data  ELEMENTS. 

The  major  distinction  between  ENTITIES  and  GROUPS  lies  in  that 
ENTITY  is  a container  of  values  of  the  ELEMENTS  of  which  it 
CONSISTS.  A GROUP,  on  the  other  hand,  is  merely  a notational 
convenience  for  naming  a set  of  data  of  which  it  CONSISTS. 
Whenever  the  analyst  finds  that  a number  of  data  ELEMENTS  appear 
in  a number  of  si'-uations  together,  he  can  simplify  his  writing 
time  and  analysis  time  by  defining  the  collection  as  a GROUP. 

Other  differences  between  ENTITIES  and  GROUPS  are  the  following. 

1)  GROUPS  can  be  CONTAINED  in  ENTITIES,  INPUTS  and  OUTPUTS, 
but  ENTITT  ES  cannot  . 
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2)  ENTITIES  (and  INPUTS  and  OUTPUTS)  can  be  CONTAINED  in  SETS, 
but  GROUPS  cannot. 

3)  ENTITIES  can  CONSIST  of  GROUPS  but  not  of  other  ENTITIES. 
GROUPS  can  CONSIST  of  other  GROUPS,  but,  of  course,  not  of 
ENTITIES. 

4)  GROUPS  can  he  used  as  SUBSETTING-CRITERIA  of  SETS  and  to 
IDENTIFY  ENTITIES,  but  ENTITIES  cannot.  ENTITIES  can  be 
RELATED  via  RELATION  statenents  and  have  ASSOCIATED  data 
consistinq  of  GROUPS. 

5)  As  far  as  PROCESSES  are  concerned,  the  saae  statenents  that 
can  be  made  about  ENTITIES  can  also  be  oade  about  GROUPS, 
though  when  the  ENTITY  is  used  in  a stateaent,  the 
appropriate  stateaent  about  the  ELEMENTS  or  GROUPS 
CONTAINED  in  the  ENTITY  aust  also  be  made  (See  Table  4.1). 

5)  Both  ENTITI’=’S  and  GROUPS  can  have  SYSTEM-PARAMETERS 

associated  with  the  CONSISTS  statement.  In  addition,  the 
ENTITY  can  have  a CARDINALITY  and  VOLATILITY  stateaent 
while  a GROUP  cannot. 

The  problem  def iner  should  specify  an  object  to  be  an  ENTITY 

when  he  wishes  to  refer  a number  of  ELEMENTS  as  a unit. 


**•3  Selection  of  Relationships 

All  relationships  in  URL  are  precisely  defined  by  statements. 
In  many  cases,  only  one  statement  will  be  legitimate.  In  some 
cases,  however,  there  may  be  a choice.  These  situations  are 
outlined  in  this  section. 


4.3.1  PECEIVES/GENE FATES  Versus  USES/UP DATES /PER IVES 

1)  RECETVES/GENER  ATES  Can  only  refer  to  INPUTS/ODTPOTS 
whereas,  USES/UPDATES/DERIVES  can  only  refer  to  "data.'' 

2)  USES  implies  that  the  data  value  of  what  is  being  USED  must 
be  available. 

UPDATES  implies  that  the  data  value  must  be  CONTAINED  in  an 
ENTITY.  DERIVES  implies  a value  is  computed. 

3)  When  INPUTS  are  USED,  OUTPUTS  are  DERIVED, 

SETS  are  USED,  UPDATED  or  DERIVED, 

ENTITIES  are  USED,  UPDATED  or  DERIVED 

this  implies  that  the  data  values  in  these  "containers'*  of 
data  values  are  being  referred  to. 
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4)  When  7FOUPS  ^re  USED,  UPDATED  or  DERIVED  at  least  one 
element  in  the  GROUP  Is  referretl  to. 

6)  The  allowable  syntax  for  which  statements  can  affect  which 
objects  is  shown  in  Table  2.4.2.  The  meaning  of  the 
statements  is  shown  in  Table  2.4.3. 

6.  ACHIEVING  GOOD  DOCUMENTATION 

Documentation  of  the  target  system,  of  j.ts  interfaces  with  the 
organization  and  its  environment,  and  of  the  system  development 
project  is  used  for  different  purposes.  Figure  5.1  outlines 
some  characteristics  of  present  manual  documentation  and  some 
desirable  characteristics  that  are  achievable  with 
computer-aided  documentation. 

To  achieve  the  potential  benefits  of  computer-aided 
documentation  requires: 

- a formal  language  which  permits  relationships  to  be  precisely 
defined . 

- a computer  program  which  provides  a method  for  enforcing 
correct  use  of  the  formal  language. 

- good  procedures  t o be  followed  by  the  analyst. 

"he  last  of  these  is  important  since  no  matter  how  good  the 
language  and  the  computer  software,  the  benefits  will  never  be 
af-ained  unless  the  tools  are  used  properly. 

In  Section  5.1  the  characteristics  of  good  documentation  are 
described  and  methods  are  suggested  by  which  the  analyst  can 
achieve  them  using  URL/UPA.  Section  5.2  summarizes  the  checks 
for  preciseness  and  consistency  which  ace  performed  by  the 
Analyzer.  Checks  which  the  analyst  can  perform  using  the 
outputs  available  from  the  Analyzer  are  described  in  Section 
5.  3. 


5.1  Char act  eristics  o^  Good  Documen  tati on 

Usually,  the  analyst  is  responsible  for  producing  documentation. 
This  section  outlines  some  major  attributes  of  good 
documentation  and  indicates  how  an  analyst  may  use  URL/URA  to 
achieve  them. 


5.1.1  Under Stan  dabi 1 ity 


Documentation  with  this 
format  and  is  presented 
persons,  no  matter  what 


characteristic  is  in  an  easy-to-read 
at  a general  enough  level  so  that 
their  background,  should  be  able  to  read 
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and  conprehend  thp  naterial  vithin. 

Reports  can  be  generated  froa  the  problea  stateaent  in  several 
coaaon  foraats,  e.g.,  flow  diagrams,  aatrices  and  at  different 
levels  of  detail.  For  example,  it  is  often  desirable  to 
initially  present  high  level  objects  and  have  subseguent  reports 
present  more  and  more  detail  about  these  objects  until 
everything  is  described  in  terms  of  their  lowest  level 
constituents.  The  analyst  can  choose  the  ordering  and  content 
of  the  reports. 


Present  Desirable  Characteristics 

Manual  of  Computer-Aided 

Docuaen  tation  Documentation 


Hard  to  Understand 
Ambiguous 
Inconsistent 
Incompl ete 
Incorrect 

Difficult  to  Analyze 
and  Evaluate 
Hard  to  Modify 


Understandable 
Precise 
consistent 
Complete 
Correc  t 

Computer-Aided  Analysis 
and  Evaluation 
Computer-Aided  Updating 


Figure  5.1  Characteristics  of 


Docuaentation 


5.1.2  Preciseness 

Documentation  with  this  quality  must  have  all  relevant 
terminology  explicitly  defined  so  that  information  presented 
cannot  be  misinterpreted. 

A computer  interpreted  language  must  have  an  accurately  defined 
syntax.  The  reserved  words  in  the  syntax  of  DRL  are  used  to 
describe  different  objects  and  the  relationships  between  the 
objects.  Definitions  of  all  reserved  words  allowed  in  the 
svntax  are  fixed  so  that  all  relationships  presented  in  the 
documentation  (UFA  reports)  are  exactly  the  same  as  those 
initially  specified  by  the  analyst  (i.e,,  there  can  only  be  one 
interpretation  of  the  information). 

5.1.3  Consistency 

Documentation  which  is  "consistent"  presents  all  the  material  in 
proper  context  and  does  not  have  statements  that  are 
conflicting,  contradictory  or  inconsistent. 

The  context  in  which  a particular  object  is  to  be  used  is 
defined  by  the  user  via  URL  statements  which  will  be  stated  in 
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the  UPA  data  base.  Any  attempts  to  use  the  previously  defined 
ob-ject  in  a conflictinq  context  will  result  in  an  error 
diagnostic.  Therefore,  use  of  UFA  maintains  consistency 
throughout  the  docu mentation . 


5.1.4  Completeness 

"^o  he  "complete,"  documentation  must  present  the  material  in 
sufficient  detail  so  that  no  reference  to  outside  sources  is 
needed  for  a thorough  understanding  of  the  subject  matter. 

Pvery  necessary  piece  of  information  must  be  available  and  no 
relationship  must  he  left  dangling. 

URL  allows  a number  of  relationships  and  objects  to  be  defined 
to  describe  an  Information  Processing  System.  The  URL 
statements  offered  provide  a thorouqh  outline  of  what  should  be 
incorporated  into  the  documentation  of  an  IPS.  The  statements 
in  URL  facilitate  the  enforcement  of  completeness. 


5.1.5  Correctness 

To  be  "correct,"  the  analyst  must  insure  that  all  relationships 
specified  in  the  documentation  are  valid,  and  that  all 
information  recorded  is  true. 

The  syntax  rules  enforced  by  URA  insures  that  all  relationships 
in  the  documentation  are  valid.  Though  it  is  impossible  to  know 
whether  the  information  recorded  is  true  or  not,  many  of  the 
reports  available  can  present  the  information  in  a format  easy 
for  the  analyst  to  check  for  errors  (e.g.,  misspellings, 
incorrect  narrative  descriptions,  etc.)  . 


5.1.6  Analyrabi  lity 

Documentation  which  is  analyzable  must  be  organized  in  such  a 
way  that  any  information  not  explicitly  stated  in  it  must  be 
easily  derived  through  some  procedure. 

5ince  all  URL  statements  are  stored  in  a data-base,  all  data  is 
easily  accessed  and  can  be  presented  in  the  form  of  a URA 
report.  In  addition,  any  new  developments  in  analyzing  the 
information  (e.g.,  Cost/Benefit  Analysis,  etc.)  can  be 
incorporated  into  the  existing  UFA  package. 


5.1,7  Ease  of  Modit ication 

Documentation  which  is  easy  to  modify  must  have  sufficient 
indexina  facilities  so  that  all  occurrences  of  a given  item  in 
the  documentation  may  be  referenced  if  and  when  a change  to  the 
item  is  required. 
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Because  the  information  use^l  in  deriving  UBA  reports  is 
contained  within  the  URA  data-base,  any  modifications  to  the 
data-base  will  be  reflected  in  reports  produced  after  the 
change.  URA  offers  several  commands  to  modify  the  data-base. 
Any  reports  generated  after  the  modifications  will  be 
up-to-date. 


'>.2  Checks  Carr ied  Out  by  the  Analyzer 

For  the  most  part,  the  characteristics  of  good  documentation  can 
be  realized  when  the  documentation  is  generated  by 
computer-aided  means.  Preciseness,  consistency,  and  correctness 
are  all  checked  by  the  Analyzer  as  new  information  is  added  to 
the  data-base  or  data  is  modified  in  it. 

URA  can  produce  several  hundred  diagnostic  and  error  messages. 
Each  is  identified  by  a number.  The  complete  list  is  given  in 
the  ‘•User  Requirements  Analyzer  User's  Manual”  in  numerical 
order  to  facilitate  correction.  Here  the  error  messages  are 
analyzed  in  terms  of  how  they  contribute  to  good  documentation. 


5.2.1  Checks  Related  to  Preciseness 

A considerable  portion  of  the  error  detection  facilities  in  the 
Analyzer  are  used  to  check  the  "preciseness”  of  new  URL 
statements  being  added  to  the  data-base.  (This  is  done  each 
time  IP-ORL  is  initiated.)  The  Analyzer  must  check  that  the 
syntax  is  correct  and  that  the  user-defined  names  given  in  the 
new  statements  are  consistent  with  names  already  in  the 
data-base,  Tf  either  of  these  conditions  fail,  an  error 
diagnostic  must  he  generated  by  the  Analyzer  to  inform  the  user 
that  the  information  to  be  stored  in  the  data-base  was  ambiguous 
or  inconsistent  with  the  information  already  in  the  data-base. 

Vo  ambiguous  or  inconsistent  information  is  stored  in  the 
dat  a-base. 

a)  Syntax  Errors 

Breaking  any  of  the  syntax  rules  of  URL  will  cause  the 
Analyzer  to  generate  one  or  more  error  diagnostics. 

Typical  syntax  errors  ace: 

- use  of  illegal  characters. 

- misspelling  of  ORA  reserved  words. 

- omission  of  semi-colon  to  terminate  line. 

Table  5.1  presents  a complete  list  of  diagnostics  produced 
when  a syntax  error  is  encountered. 

b)  Incorrect  Use  of  Names 
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It.  is  very  important  that  once  a name  is  defined  and  has  an 
associated  name  type  along  with  it  (e.q.,  PROCESS  or  SET), 
the  name  can  only  be  used  in  the  context  in  which  it  was 
defined.  Therefore,  a name  defined  to  be  a PROCESS  cannot 
also  be  used  to  define  a GROUP  of  data.  Likewise,  only 
those  relationships  specified  by  the  "User  Requirements 
Language,  Language  Reference  Manual"  can  be  used  to  relate 
to  obiects.  For  example,  a USES  relationship  between  two 
PROCESS  names  is  not  allowed  and  any  attempt  to  specify 
this  would  cause  the  Analyzer  to  generate  the  diagnostic: 

.MOST  BE  ELEMENT,  GROUP,  INPUT,  ENTITY  OR  SET 

Table  5.2  presents  a complete  list  of  the  errors  that  can 
he  encountered  when  incorrectly  using  names. 

5.2.2  Checks  As  soda  ted  with  Consistenc  y 

As  URL  statements  are  being  added  to  the  data-base,  the  Analyzer 
also  checks  that  the  new  relationships  being  specified  are 
consistent  with  the  information  already  in  the  data-base.  In 
the  previous  section,  the  Analyzer  was  shown  to  check  that  once 
a name  was  defined  to  be  a given  name  type,  it  could  not  be  used 
in  a conflicting  context  (i.e.,  as  a different  name  type).  The 
Analyzer  must  also  check  that  the  relationships  specified  for  a 
given  name  do  not  conflict.  For  example,  if  an  ENTITY  was 
defined  to  have  a CARDINALITY  of  100,  it  would  be  illogical  to 
also  say  that  its  CARDINALITY  is  50.  The  Analyzer  will  detect 
these  types  of  inconsistencies.  The  Consistency  Error  Messages 
are  listed  in  Table  5.3.  Table  5.4  presents  the  various 
inconsistencies  detected  by  the  Analyzer  according  to  name  type 
and  relationships  within  the  system  description. 
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2 NLEX  NAHE  TOO  LONG 

3 NLEX  'EOF*  NOT  POUND  BEFORE  END-OP-FILE 

4 INDBS  ERROR  OPENING  DATA  BASE  FOR  - 

5 NLEX  END-OP-DILE  IN  MIDDLE  OF  COMMENT 

7 SCAN  ILLEGAL  CHARACTER  - IGNORED 

10  REDUCE  NO  APPLICABLE  PRODUCTION  - SYNTAX  ERROR  - START 

SKIPPING 

11  STACK  ILLEGAL  SYMBOL  PAIR  - SYNTAX  ERROR  - START 

SKIPPING 

16  COHENT  END-OF-FILE  IN  COMMENT  ENTRY 

90  RHLIST  SSCN  IS  ONLY  LEGAL  TYPE  IN  DEFINE  SECTION  WHICH 

CAN  BE  MAINTAINED 

114  VLIST  ONLY  SINGLE  VALUE  OR  RANGE  ALLOWED  - IGNORED 

116  OTHERS  VALUES  ONLY  LEGAL  FOR  ELEMENT,  SYSPAR, 

OP  ATTRIBUTE-VALUE 

119  CLRCA  P0NCH=  NOT  ALLOWED  IN  THIS  IMPLEMENTATION 

201  PLIST  NAME  NOT  PART  OF  HEADER 

225  RWLIST  CANNOT  HAVE  KEYWORD  FOR  KEYWORD 

228  RWLIST  CANNOT  HAVE  SECURITY  FOR  SECURITY 

229  RWLIST  CANNOT  HAVE  SOURCE  POP  SOURCE 

231  RWLIST  SYNONYMS  ONLY  APPLIED  TO  FIRST  NAME 

232  APPLES  APPLIES  STATEMENT  ILLEGAL  WITH  THIS  NAME  TYPE 

266  ILLST  ILLEGAL  STATEMENT  IN  THIS  SECTION 


Table  5.1 

URL  Syntax  Error  Messages 
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Error 
Nura  her 


25 

HEAD 

51 

EWLIS*^ 

101 

MLIST2 

102 

NLrST2 

11B 

CLRCA 

202 

NLIST 

204 

DFFN 

207 

SSTSYN 

209 

CHKCON 

210 

PRTNUN 

211 

OTHERS 

216 

OTHERS 

217 

OTHERS 

219 

CLS  ECA 

234 

OPTRW 

235 

OPTION 

236 

OPTION 

240 

APPLES 

241 

APPLES 

246 

APPI  ES 

247 

APPLES 

24R 

APPLES 

257 

FORMSL 

267 

ILLST 

Pi  agnostic 

INVALID  HEADER  STATEMENT  - STATEMENTS 
WILL  BE  IfiNORED 

MUST  BE  SUBSETTING-CRITEPION  NAME 


NAME  ALREADY  USED  IN 
NAME  ALREADY  USED  IN 
FTLE=  NOT  A1.LCHED  IN 
NAME  PREVIOUSLY  USED 
NAME  ALREADY  USED  IN 


DIFFERENT  CONTEXT 
DIFFERENT  CONTEXT 
THIS  IMPLEMENTATION 
DIFFERENTLY  - IGNORED 
DIFFERENT  CONTEXT 
CANNOT  BE  MADE  SYNONYM  - DIFFERENT  TYPES 
STACK  OVERFLOW  WHILE  WALKING  CONSISTS  STRUCTURE 
NO  NAMES  IN  BATA  BASE 
NAME  MUST  BE  ENTITY  NAME 
NAME  MUST  BE  ENTITY  NAME  BEFORE  VIA 
NAME  MOST  BE  RELATION  AFTER  VIA 
FILE=  NOT  ALLOWED  IN  THIS  IMPLEMENTATION 
NAME  ALREADY  USED  IN  DIFFERENT  CONTEXT 
NAME  ALREADY  USED  IN  DIFFERENT  CONTEXT 
NAME  LIST  TOO  LONG  - REST  IGNORED 
KEYWORD  CANNOT  APPLY  TO  KEYWORD 
MAILBOX  CAN  ONLY  APPLY  TO  PD 
SECURITY  CANNOT  APPLY  TO  SECURITY 
SOURCE  CANNOT  APPLY  TO  SOURCE 
MEMO  CANNOT  APPLY  TO  MEMO 
NA  ME  NOT  I N DATA  BASE  - 
NO  CURRENT  SECTION 


Table  5.2 

URL  Name  Error  Messages 
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rror 
uj  bgr 


22 

RWLIS2 

43 

OTHERS 

44 

OTHERS 

60 

APPLES 

61 

PWLIST 

62 

RWLIST 

63 

RWLIST 

115 

VLIST 

117 

OTHERS 

205 

SETSYN 

212 

OTHERS 

213 

OTHERS 

214 

OTHERS 

215 

RWLIS2 

213 

OTHERS 

265 

RWLIST 
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Diagnostic 

SAME  ATTRIBUTE  ALREADY  GIVEN  WITH  DIFFERENT 
ATTRIBOTE  VALUE 

CARDINALITY  ALREADY  GIVEN  AS  SYSPAH 
CARDINALITY  ALREADY  GIVEN  AS  DIFFERENT  VALUE 
SECOND  MAILBOX  FOR  PD  ILLEGAL 
ALREADY  PART  OF  SOMETHING  ELSE 
SECOND  PD  FOB  THIS  NAME  ILLEGAL 
ALREADY  PART  OF  SOMETHING  ELSE 
MIN  NOT  LESS  THAN  MAX  - IGNORED 
DIFFERENT  VALDES  ALREADY  GIVEN 
ALREADY  SYNONYM  FOR  SOMETHING  ELSE 
RELATION  ALREADY  EXISTS  BETWEEN  TWO  OTHER 
ENTITIES 

CAN  HAVE  ONLY  ONE  CARDINALITY 
CONNECTIVITY  ALREADY  GIVEN  FOR  THIS  RELATION 
ALREADY  CONTAINS  WITH  DIFFERENT  SYSTEM 
PARAMETER 

RELATION  ALREADY  EXISTS  BETWEEN  DIFFERENT 
ENTITY 

CONNECTION  ALREADY  EXIST  WITH  DIFFERENT  VALUE 
OP  NAME 


Table  5.3 

URL  Consistency  Error  Messages 


I 
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CONSISTENCY  ERRORS 

System  SysteB  Data  Data 


Plow 

Structu  re 

Structure 

Derivation 

RWE 

61,63 

INPUT 

61,63 

OUTPUT 

61,63 

EN'^ITY 

212,218 

RELATION 

212,218 

PROCESS 

61,63 

OTHER 

205 

20  5 

205 

40,205 

System 

Size 

System 

Dynamics 

System 
Propert ies 

Project 

Management 

RWE 

62 

INPUT 

215 

62 

OUTPUT 

215 

62 

SP" 

43, U4 
213, 215 

62 

ENTITY 

43,44 
213,  214 

62 

RELATION 

43,44 
213, 214 

62 

GROUP 

215 

62 

ELEMENT 

117,115 

62 

PROCESS 

62 

INTERVAL 

215 

62 

SYSTFP 

PARAMETER 

265, 115 

62 

EVENT 

62 

CONDITION 

62 

CONDITION 

62 

PART  I USER  PEQUIREMENTS  LANRtJAGE  MANUAL 


i ! 


PAPT  I fjSEP  REQUIREMENTS  LANGUAGE  MANUAL 


IBM360/370/VS/TS0  UHL  USER’S  MANUAL 


186 


5.3  Congj,3t^ncy  and  Completeness  Checks  Carried  Out  ^ toe  Analyst 

At  some  point  in  time  in  the  development  of  the  problem  statement,  the 
^lyst  may  want  to  check  its  state  of  consistency  and/or  completeness. 

The  An^st  can  perform  these  checks  by  inspection  of  various  reports 
available  from  the  Analyzer.  This  technique  is  possible  because  all 
ormation  specified  in  the  data-base  can  be  presented  via  one  or  more 
reports.  Since  toe  Analyzer  has  checked  all  inputs  to  the  data-base  for 
syntax  and  consistency  errors,  the  problem  statement  presented  is  always 
in  a correct  state.  It  is  toe  role  of  the  Analyst  to  determine  whether 
it  is  totally  "consistent"  or  "complete". 

Tables  5.5a  and  5.5b  presents  a summary  of  all  consistency  and  completeness 
checks  to  be  carried  out  by  the  Analyst. 

Tables  5-6a  ^d  5.^  presents  a summary  of  the  benefits  of  particular  URA 
reports  in  identifying  incompleteness  and  inconsistencies  in  the  problem 
statement . ^ 
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I)  SYSTEM  FLOW 

a)  All  INTERFACES  should  GENERATE  some  INPUT,  RECEIVE 
some  OUTPUT,  or  be  RESPONSIBLE  for  some  SET. 

b)  All  INPUT'S  should  be  GENERATED  by  at  least  one 
INTERFACE. 

c)  All  INPUTS  Should  be  RECEIVED  by  at  least  one 
PROCESS. 

d)  All  OUTPUTS  should  be  GENERATED  by  at  least  one 
PROCESS. 

e)  All  OUTPUTS  should  be  RECEIVED  by  at  least  one 
INTERFACE. 


II)  SYSTEM  S-'-pUCTUFE 

a)  All  PROCESSES  without  SUBPARTS  should  have 
PROCEDURES. 

b)  SETS  with  SUBSETS  should  have  SU BSETT ING-CRITEHIA . 

c)  All  INPUTS  without  SUBPARTS  should  be  broken  down  via 
the  CONSISTS  statement. 

d)  All  OUTPUTS  without  SUBPAPTS  should  be  broken  down 
via  the  CONSISTS  statement. 


Ill)  DATA  STRUCTURE 

a)  All  ELEMENTS  should  "lable  from  an  INPUT  or 

from  a ENTITY,  or  DERj.  y some  PROCESS. 

b)  All  SETS  should  CONSIST  INPUTS,  OUTPUTS  or 
ENTITI»=’S  . 

c)  All  ENTITIES  should  be  broken  down  via  the  CONSISTS 
stat  auen  t . 

d)  All  INPUTS  should  be  broken  down  via  the  CONSISTS 
statement  if  there  are  no  SUBPARTS. 

e)  All  OUTPUTS  should  be  broken  down  via  the  CONSISTS 
statement  if  there  are  no  SUBPARTS. 

f)  Ml  RELATIONS  should  have  a BETWEEN  statement. 

g)  All  GROUPS  should  be  composed  of  ELEMENTS. 


Table  5.5a 

Summary  of  Completeness  Checks  to  be  made  by  Analyst 
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IV) 


DATA  DEPIVA'^TON 

a)  All  ELEMFNTS  should  be  USED,  UPDATED  and/or  DERIVED 


b) 

c) 

<1) 

«) 

f) 

q) 

h) 

i) 

1) 


by  at  le 
All  PROC 
PECEIVIN 
All  PPOC 
GENERATI 
All  SETS 
least  on 
All  SETS 
All  ENTI 
All  ELF.M 
All  ELEK 
All  ELEM 
or  DEPIV 
All  PELA 
PROCESS. 
All  PELA 


ast  one  PROCESS. 

ESSES  should  acquire  information  by 
G,  USING  or  UPDATING. 

ESSES  should  produce  information  by 
NG,  DERIVING,  or  UPDATING. 

should  be  USED,  UPDATED  or  DERIVED  by  at 
e PROCESS. 


should 
"•lES  sho 
ENTS  wit 
ENTS  wit 
ENTS  wit 
ED. 

TIONS  sh 


have  a DERIVATION  statement. 

uld  be  USED,  UPDATED  or  DERIVED. 

hin  an  INPUT  should  be  USED. 

hin  an  OUTPUT  should  be  DERIVED. 

hin  an  ENTITY  should  be  USED,  UPDATED 

ould  be  MAINTAINED  by  at  least  one 


TIONS  should  have  a DERIVATION  statement. 


V) 


SYSTEM 

SIZE  AN 

D VOLUME 

«) 

All 

EVEN 

TS  shoul 

d 

ha 

ve 

b) 

A 11 

PPOC 

ESSES  Sh 

o 

uld 

h 

c) 

All 

SETS 

should 

h 

ave 

a 

d) 

All 

SETS 

should 

h 

a ve 

a 

e) 

All 

SETS 

should 

h 

ave 

a 

f) 

All 

ENTI 

TIES  sho 

u 

Id 

ha 

q) 

All 

ENTI 

TIES  sho 

u 

Id 

ha 

h) 

All 

INPU 

TS  shoul 

d 

ha 

ve 

i) 

All 

OUTP 

UTS  shou 

Id  hav 

1) 

All 

RELA 

TIONS  Sh 

o 

uld 

h 

All 

RELA 

TIONS  sh 

o 

uld 

h 

a HAPPENS  statement, 
ave  a HAPPENS  statement. 
CARDINALITY  statement. 
VOLATILITY-SET  statement. 
VOLATILITY-MEMBER  statement, 
ve  a CARDINALITY  statement, 
ve  a HAPPENS  statement. 

a HAPPENS  statement, 
e a HAPPENS  statement, 
ave  a CARDINALITY  statement, 
ave  a CONNECTIVITY  statement. 


VI)  SYSTEM  DYNAMICS 

a)  Each  EVENT  should  be  associated  with  at  least  one 
CONDITION  or  PROCESS. 

b)  Each  CONDITION  should  be  associated  with  at  least  one 
EVENT  or  PROCESS. 

c)  Each  CONDITION  should  have  a TRUE  WHILE  or  FALSE 
WHILE  statement. 


Vri)  SYSTEM  PROPERTIES 

a)  All  KEYWORDS,  ATTRIBUTES,  SOURCES,  SECURITIES  and 
TRACE-KEYS  should  APPLY  to  some  other  URL  names. 


VITI)  PROJECT  MANAGEMENT 

a)  All  PPORlEM-nEFI  NERS  should 

h)  All  PROBLEM-DEFINERS  should 

description  of  a t least  one 


have  a MAILBOX, 
be  RESPONSIBLE  for  the 
URL  objects. 


Table  5.5a  (continued) 
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Analyzer  Commands 


ATTRIBUTE  IN^OR MATT  ON  REPORT 
CONSISTS  COMPARISON  MATRIX 
CONTENTS  REPORT 
DATA  PROCESS  REPORT 
FOPMA’^TED  PROBLEM  STATEMENT 


FRECUENCY  REPORT 
NAME  GEN 
PTCTU»>E 

PROCESS  INPUT/OUTPUT 
PUNCHED  COMMENT  ENTRIES 


C 

ompleteness 

Chec 

ks 

VII 

a 

III 

c,  I 

lid,  me 

r I 

Ilq 

III 

c,  I 

lid,  llle 

, I 

Ilg 

ic. 

Id; 

IVa,  IVb 

, I 

VC, 

IVd,  I 

Vf 

la- 

le; 

ITa-IId; 

III 

a- II 

ig; 

IVa- 

IVf, 

I Vi 

, IV 

j;  Va-Vk; 

VI 

a- VI 

c;  VII 

Ib 

Va, 

Vb, 

Vh,  Vi 

Villa, 

Vlllb 

la. 

Ib, 

Ic,  Id, 

le; 

Ilb 

, lie. 

Ild 

IVb 

, TV 

c 

I Ve 

, IV 

■),  Vd,  Ve 

. V 

g 

Table  5.5b 

URA  Reports  that  may  be  used  to  Visually  Check 
for  Completeness  of  the  Problem  Statement 

(See  Table  5.5a) 
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Table  5.6a 
URA  Report 

CONSISTS  COMPARISON  - 
MATRIX 


Completeness  Checks 

All  INPUTS,  OUTPUTS,  ENTITIES  and  GROUPS 
ace  broken  down  to  ELEMENTS  at  the  lowest 
level . 

All  necessary  ELEMENTS  are  defined  in  the 
data  structure  for  a particular  INPUT, 
OUTPUT  or  ENTITY. 


CONSISTS  MATRIX  - All  GROUPS  and  ELEMENTS  belong  to  higher 

level  data  structures. 

- All  SETS  broken  into  INPUTS,  or  OUTPUTS 
or  ENTITIES* 


CONTENTS  REPORT  - All  INPUTS,  OUTPUTS,  ENTITIES  and  GROUPS 

are  broken  down  to  ELEMENTS  at  the  lowest 
level . 

- All  SETS  broken  into  INPUTS,  or  OUTPUTS 
ENTITIES 

DATA  PROCESS  REPORT  - All  INPUTS  RECEIVED  by  some  PROCESS* 


- All 

INPUTS  USED 

by  some  PROCESS* 

- All 

OUTPUTS 

GENE 

RATED 

by  some 

PR 

OCESS* 

- All 

OUTPUTS 

DERI 

VED  by 

some  PROC 

ESS* 

- All 

ENTITIES 

and 

SETS 

DERIVED 

by 

some 

PPOC 

ESS* 

- A’l 

ENTITIES 

and 

SETS 

DEF IVED 

an 

d USED 

some 

PROCESS* 

- All 

ENTITIES 

and 

SETS 

are  UPDATE 

D and 

USED 

by  some 

PROCESS  * 

All  GROUPS  and  ELEMENTS  are  DERIVED  or 
UPDATED  or  USED  by  some  PROCESS* 


- All 

PROCESSES 

USE  lata  and 

DERIV 

E or 

UPDA 

TB  data* 

- All 

PROCESSES 

which  DERIVE 

data 

also 

USE 

data 

1 

- All 

PROCESSES 

which  UPDATE 

data 

also 

USE 

data 

1 

- All 

PROCESSES 

interact  with 

data 

i n 

soma 

way* 

DICTIONARY  REPORT  - All  names  should  have  a narrative 

DESCRIPTION  and 
RESPONSIBI  E-PROBLEM-DEFINER 


i 


IDENTIFIER  INFOP 
MATICN  REPOPT 


Determines  which  ENTITIES  have  and 
do  not  have  IDENTIFIERS 


FORHA'’'TED  PROBLEM 
STATEMENT 


The  description  of  each  name 
checked  against  all  possible 
for  that  name. 


can  be 
sta  tements 


* Computer-aided  analysis 

i 
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FREQUENCY  REPORT 

KMTC  INDEX 
NAME  OEN 

NAME  LIST 

PICTURE 


ATTRIBUTE  REPORT 


PROCESS  INPUT/ 
OUT  PUT 


All  INPUTS,  OUPTPUTS,  PROCESSES  ani 
EVENTS  shoulfi  have  a HAPPENS  statement 


All  names  of  a particular  type  (e.q., 
PROCESS)  have  been  defined  for  a 
particular  problem  statement 

Names  which  have  synonyms  in  the  real 
world  should  have  them  in  the  problem 
stat  ement 

[given  in  Table  2.1b') 

All  names  should  be  involved  in  structure 
and/or  information  flow  of  the  problem 
stat  ementi 

All  ATTRIBUTES  have  VALUES 
All  names  have  appropriate 
ATTRIBUTES/ATTRIBUTE  VALUES  assigned  to 
them 

All  PROCESS  interact  with  data 
in  some  manner 

All  PROCESSES  USE  or  RECEIVE  information* 
All  PROCESSES  GENERATE,  DERIVE  or  UPDATE 
i nf o rraa  tion* 

All  PROCESSES  have  DESCRIPTION  and 
PROCEDURE  statements 

Table 

(Continued) 
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Table  5.6b 
URA  Report 

CONSISTS  COrPARTSON 
MATRIX 

CONSISITS  MA'^RIX 

CONTENTS  REPORT 

OAT  A PROCESS  REPORT  - 


DICTIONARY  REPORT 


TDFNTIFIEP  INFOR- 
MATION REPORT 


FORMATTED  PROBLEM 
STATEMENT 

PnECUFNCY  REPORT 

KMIC  INDEX 

NAME  GEN 

NAME  LIST 


Consistency  Checks 


Similarities  in  data  structures  of  INPUTS 
OUTPUTS  and  ENTITIES  can  be  rationalized 
for  a particular  problem  statement. 

Determines  whether  or  not  the  use  of  the 
CONSISTS  statement  in  describing 
structure  is  consistent. 

Determines  whther  or  not  the  use  of  the 
CONSISTS  statement  in  describing 
structures  is  consistent. 

Determines  whether  or  not  the  use  of 
RECEIVES  and  GENERATES  statements  in 
describing  the  system  flow  aspect  of  the 
system  is  consistent. 

Determines  whether  or  not  the  use  of 
USES,  UPDATES  and  DERIVES  statement  in 
describing  the  data  derivation  aspect  of 
the  system  is  consistent. 

Synonyms  and  descriptions  should  apply  to 
each  name  accurately 

Determines  whether  or  not  the 

use  of  IDENTIFIERS  is  consistent  through 

the  problem  statement. 

Determine  whether  the  complete 
PSL  description  is  accurate  for  a 
particular  name  (e.g.,  check  that  the 
DESCRIPTION  matches  what  is  given  by 
other  PSL  statements) 

Determines  whether  or  not  the  manner  in 
which  frequencies  (HAPPENS  statement)  are 
assigned  is  consistent. 


Determines  whether  or  not  conventions 
used  in  assigning  names  is  consistent 


Determines  whether  or  not  naming  is 
consistent 

Determines  whether  or  not  name  types  have 
been  assigned  correctly. 


Determines  whether  or  not 
consistent 

Determines  whether  or  not 
been  assigned  correctly 
Determines  whether  or  not 
been  assigned  correctly 


naming  is 
name  types  have 
SYNONYMS  have 
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PICTURE 

- Deteraines  whether  or  not  the  na «e  the 
PICTURE  is  generated  for  relates  to  the 
structure  and  information  flow  aspects  of 
the  problem  statement  correctly 

ATTRIBUTE  P i PORT 

Determine  whether  or  not  the  conventions 
of  assigning  ATTRIBUTES  is  consitient 

PROCESS  INPUT/ 
OUTPUT 

- Determine  whether  or  not  the 

- manner  in  which  PROCESSES  ace  described 
is  consistent 

Table  5 . 6b  (con ' t) 
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Index 


computer  4,  19,  20,  34,  35,  36,  113,  163,  176,  177 
data-base  4,  6,  ii,  23,  34,  35,  36,  37,  38,  62,  63,  68,  85,  116, 
121,  124,  12*^,  131,  143,  171  , 178,  179,  180,  186 
function  18,  87,  97,  154,  155,  156,  157 
lanquaqe  4,  5,  36,  37,  58,  59,  115,  125,  171,  176,  177 
systems  1,  5,  14,  29,  60,  68,  78,  114,  122 

APPLIES  25,  26,  27,  2«,  32,  115,  116,  119,  122,  123,  168,  170, 
181 


ASSERT  25, 

26, 

32, 

1 15, 

117,  120, 

128, 

129, 

132, 

136  , 

1 39, 

142, 

147, 

149, 

153, 

159, 

150, 

162, 

163, 

164, 

165 

, 166, 

167, 

168 

170 

ASSOCIATED 

25, 

26, 

27,  31,  80, 

81, 

82, 

84,  151, 

175 

ASSOCIATED 

-DATA 

25, 

26, 

27,  31 

, 80 

r 81, 

148, 

149 

, 151 

ATTRIBUTE 

13,  15,  21  , 22 

, 25, 

26, 

28,  32,  38 

, 77 

, 114, 

115, 

116 

117, 

119, 

120, 

121, 

126, 

120, 

132, 

136, 

139 

, 142, 

147, 

1 49 

153, 

159, 

160, 

162, 

163, 

164  , 

165, 

166, 

167 

, 168, 

170, 

183 

188, 

189, 

1'»1, 

193 

ATTRIBUTE- 

VALUE 

13, 

15, 

21,  22 

, 32 

, 38, 

114, 

115 

, 116, 

119, 

126 

128,  168,  181 

BECOMES  109,  110,  1^8,  162 


BECOMING  104 

, 105, 

108, 

161 

BETWEEN  25, 

26, 

80, 

ei. 

82, 

83, 

% 

GO 

147  , 

149, 

151, 

183, 

187 

Command  47, 

54, 

120 

, 121 

, 125 

CARDINALITY 

25, 

26, 

27, 

31  , 

85  , 

99, 

103, 

104, 

142, 

146, 

149 

175,  180, 

183, 

188 

CAUSED  25,  26, 

27, 

31,  104,  1 06, 

108, 

109, 

162 

CAUSES  25,  26, 

27, 

31,  1 04,  105, 

108, 

1 35, 

161, 

162 

CLASSIFICATION 

13, 

15,  21,  22,  25 

r 27, 

31, 

32, 

38,  71, 

126,  135, 

138, 

141,  142,  146 

, 153 

, 168 

CONDIT'ION  1 3,  1 5,  19,  31,  33,  38,  104,  105,  106,  108,  1 09,  110, 


126,  1 35,  157, 

158, 

160,  161, 

162,  163, 

184, 

188 

CONNECTIVITY  25,  26, 

27, 

31,  83,  84 

, 99,  100 

, 103 

, 148,  149, 

183,  188 

CONSISTS  28 , 26  , 27  , 

31, 

71,  80,  81 

» 82,  83, 

85, 

86,  87,  99, 

100,  1 03,  1 34, 

137, 

139,  140, 

144,  151, 

160, 

174,  175,  182, 

187,  189,  190, 

192 

CONSUMED  25  , 26,  27, 

32, 

111,  112, 

114,  165 

CONSUMES  25  , 26  , 27  , 

32, 

111,  112, 

113,  114, 

164 

CONTAINED  25,  26,  27 

, 31 

, 71,  30,  01,  82,  84 

, 86, 

87,  94,  98, 

90,  100,  133,  137,  139,  148,  150,  174,  175 


CONTENTS  86,  87 

, 189,  190,  192 

DEFIN’'  38,  126, 
DELETE-PSL  59 

168 

, 169,  170, 

172, 

181 

DEP-^VATION  15, 

25, 

30,  31,  83, 

96, 

97, 

145, 

148 

, 149 

, 188 

DERIVE  40,  88, 

89, 

91,  93,  134 

, 140 

, 144,  151, 

152, 

155,  172, 

‘>73,  190, 

191 

DERIVED  25,  26, 

27, 

31,  88,  89 

, 92, 

96, 

97, 

98, 

138, 

139,  141, 

144,  1 45, 

152, 

153,  154, 

156, 

172, 

173 

, 174,  1 75,  176,  187 

180,  190 

DERIVES  25,  26, 

27, 

31,  00,  39 

, 91, 

92, 

93, 

94, 

95, 

97,  120, 
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129, 

155, 

156, 

157, 

175, 

192 

DESCRIPTION  1, 

25, 

30,  32 

39, 

59, 

60, 

97,  115,  116,  120,  1 

7 

t / , 

129, 

132, 

136, 

139, 

142, 

147, 

149, 

153, 

159,  160,  162, 

163 

164, 

165, 

166, 

167, 

168, 

170, 

190, 

191, 

192 

DESIGNATE 

26,  32,  38,  126 

, 171 

DICTIONARY 

121, 

190 

, 192 

ELEMENT  13 

, 15, 

17, 

18,  19,  22 

, 31, 

38, 

39, 

77,  78,  80,  81, 

8 2, 

83,  86,  87 

, 88 

, 89, 

91,  92,  93 

, 94 

, 95, 

96,  97,  98,  99 

r 

103, 

120, 

126, 

134, 

137, 

138, 

139, 

140  , 

141,  145,  148, 

150 

1^1, 

152, 

153, 

155, 

156, 

172, 

174, 

175, 

180,  181,  184, 

187 

188, 

190 

ENTITY  13, 

15, 

16, 

17,  19 

31, 

38, 

78, 

79,  80,  81,  82,  83, 

84, 

86,  87,  88 

r 89 

, 91, 

92  , 93,  94 

, 95 

, 96, 

97,  98,  99,  10  3, 

104, 

126, 

139, 

140, 

141, 

142, 

143, 

144, 

145,  146,  147, 

148 

149, 

150, 

151, 

155, 

156, 

169  , 

172, 

173, 

174,  175,  180, 

182 

183, 

1 84, 

187, 

188, 

190, 

192 

EVENT  13, 

15,  19,  31  , 33, 

38, 

39,  99,  100,  103,  104,  10  5,  106, 

108, 

1 09, 

110, 

126, 

135, 

157, 

158, 

161 , 

162,  163,  184, 

100 

190 

FALSE  104,  105,  10fi,  108,  109,  110,  136,  158,  159,  160,  161, 
162,  163,  188 

FORM  ATTEO-PFOBL  EM-STATEMENT  87 


'■REOUENCY  103,  189,  190,  192 


GEN  EPATED 

10, 

- 11. 

, 23, 

25, 

26,  27 

, 31, 

39, 

64, 

65,  66 

, 68, 

73, 

75, 

95, 

97, 

132, 

133 

, 136, 

137, 

139, 

172 

, 174, 

107, 

190 

GENERATES 

10, 

r 11. 

. 23, 

25, 

26,  27 

, 31. 

38, 

39, 

64,  65 

, 66, 

68, 

89, 

94, 

95, 

131, 

154 

, 175, 

192 

GROUP  13, 

15, 

r 17, 

, 1 8, 

22, 

31,  38 

, 39, 

77, 

78, 

80,  81 

, 82, 

83, 

86, 

87, 

88, 

89, 

91, 

92  , 93, 

94. 

96, 

97, 

98,  99, 

10  3, 

104 

126,  134,  137,  138,  139,  140,  141,  148,  150,  151,  152,  153, 
155,  156,  172,  174,  175,  176,  180,  184,  187,  190 


HAPPENS  25 

, 26 

, 27 

, 31,  99 

, 100 

> 103, 

1 04, 

135 

173, 

188, 

191 

, 192 

IDENTIFIED 

25, 

26, 

27,  31, 

80, 

81, 

82, 

86, 

140 

IDENTIFIES 

25, 

26, 

27,  31, 

80, 

82, 

83, 

151 

INCEPTION 

25, 

26. 

27,  31, 

1 05, 

106 

, 108,  162 

INCEPTION 

A OSES 

25, 

26, 

27, 

31, 

105, 

, 108, 

158 

INPUT  9, 

10 

, 11» 

13, 

15, 

16, 

17, 

23, 

29,  31 

, 33, 

38, 

39, 

64, 

65, 

66, 

68 

, ■'2, 

73. 

75, 

76, 

77, 

78, 

79,  80 

, 81, 

82, 

87, 

88, 

89, 

91, 

92 

, 93, 

94, 

97, 

98, 

99, 

100, 

, 103, 

104, 

105, 

106, 

, 108 

9 

109, 

120,  126, 

131, 

132, 

133, 

134, 

135, 

136, 

139, 

14  3, 

144, 

150, 

154,  155, 

156, 

157, 

161 , 

162, 

169, 

171, 

172, 

173, 

174, 

175, 

180,  184, 

187, 

188, 

189, 

190, 

191, 

192, 

193 

INPUT-PSL 

59 

INTERFACE 

10  , 11,  13 

, 14 

, 15, 

29, 

31,  30 

, 39 

, 64, 

65, 

66,  68 

f 

72, 

75  , 76  , 77, 

97, 

126, 

131, 

132, 

133, 

136, 

137, 

143, 

171, 

172, 

173,  174, 

184, 

107 

INTERRUPTED  25,  26,  27,  31,  105,  106,  108,  109,  157,  15  8 
INTERRUPTS  25,  27,  31,  105,  108,  135,  158,  161,  163 


INTERVAL  13,  15,  19,  19,  31,  30,  98,  99,  103,  104,  126,  159, 


160, 

184 

KEYWORD  13 

, 15, 

21. 

22,  25,  26 

. 28, 

32, 

38,  114,  115,  1 16 , 119, 

120, 

121, 

126, 

127,  128, 

132, 

136, 

139,  142,  147,  149,  153, 

159, 

160, 

162, 

163,  164, 

165, 

166, 

167,  168,  169,  170,  181  , 
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182,  188 
KWIC  191,  192 
LIST  182,  191,  192 

MATLEOX  13,  IS,  21,  25,  26,  28,  32,  38,  122,  123,  124,  126,  167, 
169,  170,  182,  183,  188 

MAINTAINED  25,  26,  27,  31,  88,  92,  96,  148,  149,  169,  181,  188 
MAINTAINS  25,  26,  27,  31  , 3 8,  88,  91,  156,  157 


MAKE  25, 

26, 

27, 

31, 

105 

, 106 

, 109,  136 

, 158,  159,  163 

MEA  SURED 

25, 

26, 

27, 

32, 

111, 

112,  113, 

165 

MEASURES 

25, 

26, 

27, 

32, 

111, 

112,  113, 

166 

MEMO  13, 

15, 

21  , 

22, 

32, 

38, 

114,  116, 

117,  119,  121,  1 26,  129, 

167,  168,  182 
NAHE-GFN  120,  121,  125 

OUTPUT  9,  1 1 , 1 3,  1 5,  16,  17,  23,  29,  31,  33,  38,  39,  64,  65, 


66,  68,  72,  T5, 

76, 

77, 

78,  79 

, 80, 

81, 

82  , 

87,  88 

, 89 

, 91 

92,  93,  95,  96, 

87, 

98, 

99,  100,  103,  104,  120,  126,  131, 

136,  1 37,  138, 

139, 

143, 

144  , 

145, 

150, 

154, 

155, 

156, 

169 

171,  172,  173, 
193 

174, 

175, 

184, 

187, 

188, 

189, 

190, 

191, 

192 

Parameter  71 
PERFORMED  25,  26,  27 

, 32 

, 111 

, 112, 

113, 

114, 

159 

PERFORMS  25,  26  , 27, 

1 11 

r 112 

, 113, 

114, 

164 

PICTURE  68,  76,  97, 

189, 

191, 

193 

PROELEM-DEFINEF  13, 

15, 

21,  32,  38, 

122, 

123, 

124 

, 126, 

167 

9 

169,  182,  183, 

188 

PROCEDURE  25,  30,  31 

, 59 

, 77, 

88,  96,  97 

, 110 

, 157,  191 

PROCESS  9,  10,  11,  13,  15,  18 

, 19, 

20,  21,  22 

, 23 

, 31, 

33, 

37, 

38,  39,  64,  65, 

66, 

68, 

72,  73 

, 75, 

76, 

77, 

85,  87 

, 88 

/ 89 

91,  92,  94,  95, 

96, 

87, 

98,  99 

, 100 

, 103 

, 104,  105 

, 106, 

108,  109,  1 10, 

111, 

112, 

113, 

114, 

12C, 

126, 

127, 

128, 

129 

132,  1 33,  134, 

135, 

136, 

137, 

138, 

140, 

141, 

142, 

144, 

145 

146,  148,  151, 

152, 

15  3, 

154, 

155, 

156, 

157, 

158, 

159, 

161 

162,  16  3,  164, 

165, 

166, 

169, 

172, 

173, 

175, 

180, 

18  4, 

187 

188,  189,  190, 

191, 

192, 

193 

PROCESSOR  1 3,  1 5,  1 9,  20,  22,  32,  38,  72,  75,  88,  96,  111,  112, 


113 

, 114,  126, 

135, 

138,  142, 

146, 

153, 

159, 

163, 

164, 

165 

RECEIVED 

10, 

11  , 

23, 

25, 

26 

, 27 

r 31 

, 39, 

40, 

58, 

64 

, 65 

, 66, 

68 

73, 

75, 

94, 

97, 

132 

, 133, 

136, 

137, 

139, 

172 

9 

187, 

1 90 

RECEIVES 

10, 

11  , 

23. 

24, 

25 

, 26 

, 27 

, 31, 

38. 

64, 

65 

, 66 

, 68, 

89 

94, 

95, 

131 

, 154,  175, 

192 

RELATED 

25, 

26, 

27, 

80, 

81, 

82, 

83, 

140, 

175 

RELATION 

13, 

15, 

17, 

38, 

79 

, 80 

, 81 

r 82, 

83, 

84, 

85 

, 88 

» 91, 

92 

96, 

97, 

99, 

100 

, 103, 

126, 

139 

, 147 

, 148 

, 149, 

151 

, 156 

9 

175,  182,  183,  184,  187,  188 

RESOURCE  13,  15,  20,  32,  38,  111,  112,  113,  114,  126,  165,  166 
RESOURCE-USAGE  25,  26,  27,  32,  111,  112,  113,  114,  159 
RESOURCE-USAGE- PARA  METER  13  , 20,  38  , 111,  112,  113,  114,  126, 

165 

RESOURCE-USAGE- PARA  METER-VALUE  25,  26,  111,  166 

PESPCNSIBLE  25,  26,  27,  32,  64,  65,  68,  122,  123,  131,  167,  187, 
188 

PESPCNSIBLE- INTERFACE  25,  26,  27,  31,  65,  143 
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RESPONSIBLE- PROBLEM 

-DEEINER  25,  26, 

28, 

122, 

123,  129, 

^2, 

1 36 

139,  142, 

147, 

149,  153,  159, 

160, 

162, 

163,  164, 

165, 

166 

168,  170, 

190 

SECURITY  13,  15 

, 21 

, 22,  25,  26,  28 

, 32 

, 38, 

115,  116, 

117, 

119 

121,  126, 

130, 

132,  136,  139, 

142, 

147, 

149,  153, 

159, 

160 

162,  16  3, 

164, 

165,  166,  167, 

168, 

169, 

170,  181, 

18  2, 

188 

SECURITY-ACCESS 

-RIGHT  25,  27,  88,  96,  1 32,  135,  138,  142,  153, 

157,  164 

SEE-MEMO  25,  26 

, 28 

, 32,  115,  116, 

117, 

119, 

129,  130, 

132, 

136 

139,  142, 
167,  170 

147, 

149,  153,  159, 

160, 

162, 

163,  1 64, 

165, 

166 

SET  9,  11,  13, 

15, 

17,  29,  31  , 37  , 

38, 

64,  65 

, 66,  68, 

72, 

73, 

75,  80,  81 

r 02 

, 83,  86,  87,  88 

. 89 

, 91, 

92,  93,  95 

, 96 

, 97 

98,  sq,  100,  1 03,  104,  126,  131,  133,  134,  137,  139,  142, 

14  3,  1 44, 

145, 

146,  147,  150, 

155, 

156, 

169,  172, 

174, 

175 

180,  184, 

187, 

188,  190 

SOURCE  13,  15, 

21, 

22,  25,  26,  28, 

32, 

38,  115,  116,  117,  119, 

121,  126, 

130, 

132,  136,  139, 

142, 

147, 

149,  153, 

159, 

160 

162,  1 6 3, 

164, 

165,  166,  167, 

168, 

169, 

170,  181, 

182, 

1 88 

STRUCTURE  31,  71  , 76,  81  , 1 82,  187 

SUBPAPTS  25,  26 

, 27 

, 31,  71,  72,  73 

, 75 

, 76, 

77,  112,  114, 

132, 

133,  1 34, 

137, 

155,  157,  164, 

137 

SUBSET  25,  26, 

27, 

31,  71,  72,  73, 

76, 

143 

SUBSETS  25,  26, 

27, 

31  , 71  , 72,  75, 

76, 

193, 

144,  187 

SUBSETTING-CRTT  ERIA 

25,  26,  27,  31, 

80, 

1U3, 

144,  175, 

187 

SUBSFTTTNG-CRITEPION  13,  25,  26,  27 

, 31 

, 38, 

80,  81,  82 

, 126, 

150,  1 56, 

169, 

181,  182 

SUMMARY  123 

SYNONYM  12,  13, 

15, 

21,  25,  26,  28, 

32, 

38,  1 14,  115,  116, 

120, 

121,  128, 

126, 

127,  132,  136, 

139, 

142, 

147,  149, 

150, 

153 

159,  160, 
183,  192 

162, 

163,  164,  165, 

167, 

168, 

170,  171, 

181, 

182 

SYSTEM- PARA  METER  13 

, 15,  18,  19,  31 

, 38 

, 80, 

98,  99,  100,  104, 

114,  126, 

134, 

137,  139,  149, 

160, 

169, 

170,  175, 

181, 

183 

TERMINATED  25, 

26, 

27,  31,  105,  1C6 

, 108,  109 

, 157,  158 

TERMINATES  25, 

26, 

27,  31,  105,  1 08 

, 135,  158 

, 161,  163 

TERMINATION  25,  26,  27,  31,  105,  1C6,  108,  162 
'^EPMINATION-CAUSES  25,  26,  27,  31  , 105,  108,  158 


TTMES-PEP 

135, 

133, 

157, 

163 

TRACE-KEY 

13, 

15,  21 

, 23 

, 26, 

28, 

32,  38 

, 115,  116 

, 117,  119 

9 

121, 

126, 

1 30, 

131, 

132, 

136, 

139, 

142, 

147, 

149,  153, 

1 59, 

160, 

162, 

163, 

164  , 

165, 

166, 

167, 

168, 

169, 

170 

TRIGGERED 

25, 

26,  27 

, 31 

, 105, 

106 

, 108, 

109 

, 110, 

157,  158 

TRIGGERS  25  , 26  , 27, 

31, 

105, 

108, 

110, 

135, 

158, 

161,  163 

TRUE  104, 

105, 

106, 

108, 

109, 

110, 

136, 

158, 

160, 

161,  162, 

163  , 

188 

UPDATE  64, 

68, 

88,  89,  91,  9 3, 

134 

, 140, 

141 

, 194, 

151,  152, 

155, 

173, 

190, 

101 

UPDATED  11 

, 25 

, 26, 

27, 

31,  64 

, 65 

, 66, 

88, 

92,  96 

, 97,  98, 

139, 

141, 

145, 

152, 

153, 

156, 

172, 

175, 

176, 

188, 

190 

UPDATES  10 

, 11 

, 25, 

26, 

27,  31 

, 64 

, 66, 

88, 

89,  91 

, 92,  93, 

94, 

95, 

97, 

156, 

1 57, 

175 

, 192 

. 5, 

r 10, 

- 11, 

12, 

34, 

35,  36, 

37, 

40, 

58,  59,  60, 

r 62, 

63, 

75, 

96, 

120, 

121, 

124 

, 125, 

128, 

1 32, 

, 171,  176, 

177, 

178, 
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179, 

180, 

186, 

189 

URL  «J,  5, 

6,  8, 

9, 

10,  11 

, 12 

, 13 

$ 

19, 

16,  18 

, 20,  21, 

22, 

23, 

2U, 

25,  26 

r 29 

, 31, 

32, 

39, 

35 

, 36 

, 37, 

38, 

39,  40 

, 91 

, 58 

■59, 

60,  62 

, 63 

, 64, 

65, 

66, 

70 

, 71 

, 74, 

75, 

77,  78 

, 81 

, 82 

83, 

84,  87 

, 90 

, 91, 

92, 

98, 

100,  103,  108, 

112,  114,  115, 

116, 

119, 

120, 

121, 

122, 

123 

$ 

124, 

125, 

126 

, 128, 

129, 

130 

147, 

167, 

168, 

169, 

170, 

171 

$ 

172, 

175, 

176 

, 177, 

178, 

179 

180, 

181, 

182, 

183, 

188 

USING  8 7, 

89,  91,  93,  96, 

97, 

120 

9 

129, 

138, 

141 

, 195, 

149, 

152 

156, 

171, 

188 

UTTITZFD  25,  26,  27,  31,  71,  72,  73,  75,  76,  92,  97,  155 
UTILIZES  25,  26,  27,  31,  71,  72,  73,  75,  76,  92,  155 


VALUES  25, 

26, 

2-^, 

31, 

80, 

82,  99 

, 103,  112,  114,  119,  153, 

181, 

183, 

191 

VOLATILITY 

25, 

30, 

31, 

103 

, 192, 

175 

VOLATILITY 

-MEMBER 

2S 

30, 

31,  146 

, 188 

VOLATILITY 

-SET 

25, 

30, 

31, 

146,  188 

WHILE  25, 

30, 

31, 

105, 

106 

, 109, 

110,  160,  161,  182,  183 

